Bogdan Mircea: Hey, Patrick.
Patrik Stas: good morning!
Patrik Stas: Is the
Patrik Stas: Hi innocence at your pilot?
Patrik Stas: I'm I'm not sure
Patrik Stas: if it's a malt. or
Patrik Stas: well, anyway.
Patrik Stas: oh, we have 9
Patrik Stas: and
Naian: Hi.
Patrik Stas: good to have yet.
Naian: And
Patrik Stas: we we get more people join us.
Patrik Stas: gonna start in the short moments.
Patrik Stas: I it is a I. Okay.
Patrik Stas: it's interesting. I remember, actually the I think the first time the innocence autopilot icon connected. I was actually a person. And I guess it was innocent. It was innocent grades.
Bogdan Mircea: It actually says that it's his book.
Patrik Stas: Yeah, right? Like, I'm a I assistant helping innocent rates taking notes. okay. You see, it's like personal. But
Patrik Stas: but I don't think it's actually for personal I don't know otherwise. Oh, who knows? Maybe I'm just
Patrik Stas: to an untrustful to this. AI. But maybe it's actual, genuine person just saving their time.
Patrik Stas: anyway. if you hear us innocence, other pilot, it will be happy. You sometimes. Don't join us in person. If if these words get you through the Transcript.
Patrik Stas: anyway, let's get started, so I'll share my screen
Patrik Stas: just short moments.
Patrik Stas: Holds up all the unimportant windows I have.
Patrik Stas: I think that's good.
Patrik Stas: Alright, so we'll come to July 22,023. Our community call. And that trust policy of hyper Ledger is in effect.
Patrik Stas: and
Patrik Stas: and yeah, let's get started.
Patrik Stas: So I don't think there's any introductions today. it's not a new people.
Patrik Stas: I'll be guttery kind of Well, I I I did this in, inspired by other other meetings, I that under this. recently, I I added these kind of points to to make sure that
Patrik Stas: if you if you guys have anything
Patrik Stas: on mine, you would like to add to agenda. You can like this pointed out now so we can
Patrik Stas: adjusted
Bogdan Mircea: I added. Some stuff just a couple of minutes ago to the end meeting discussion, but just to just keep in mind. But they they they're already there. So nothing new to that.
Patrik Stas: Alright so I guess that that would be it.
Patrik Stas: you know. Nevertheless, if you if if someone will have an idea and a thought you would like to put out there feel free, and the time during the meeting, nevertheless.
Patrik Stas: yesterday we had a presentation on Aries for group call. So the recording is available there. You would like to see we did the presentation of
Patrik Stas: I. there will be upload that diagram we created. And I also put it here
Patrik Stas: as kind of status overview of what we are, what we did, what we are doing, what we are planning to do.
Patrik Stas: next up I kept this item here in case that it kind of option optional update. So
Patrik Stas: I see that we have only 9 here. So if you would like to give an update you know you you can.
Patrik Stas: Would you like to say say a few words about
Patrik Stas: you know what? What's your latest progress is?
Naian: Hello, yeah.
Naian: So yesterday, in the slack chat I was recommended to look into
Naian: feature flags, and to basically
change the implementation of the database back in from in any database
Naian: to selecting one particular database at compile time rather than
selecting the database at Runtime.
Naian: So
I looked into feature flags. And I think I've implemented that in on the server. Now, the sender link in chat.
Naian: So basically, what I do is I have some
Naian: teacher flag, I mean future flag based. code.
Naian: When you give a feature flag saying, Okay, we're going to activate my sequel.
Naian: Then it's going to only load the code that's required to give a Mysql pool
Naian: and so on.
Naian: So for postdress. I'll do postless by default. I have activated my sequel.
Naian: and if someone says they want posters, they can activate posters. If someone says they want any pool that is runtime selected database. Then they can do that also.
Yeah. So that's where I'm right now.
Naian: Since yesterday.
Patrik Stas: right
Patrik Stas: cool, cool, and we have lots of discussion about like the overall architecture and the protocols and stuff like that, right
Patrik Stas: is is what? What's your kind of,
Patrik Stas: you know, maybe feeling of
Patrik Stas: like, do you feel like, you understand? Like the big picture like, do you have some like kind of shadow areas? Or you feel like you still need to kind of shed some more light on, but it's a little bit mysterious. What's your kind of, you know.
Patrik Stas: feel or thought on the overall project scope and like the the work ahead and things like that
Naian: right? I I think I'm getting a hang of it right now, like, especially on one side, working on the server. And then we had, like the discussion on Tuesday, you explained through the connection protocol and the whole flow of the mediator with the Rfcs. So I do have some understanding of it right now, of course. the interaction with Aries. We see export.
That for me right now is a blur.
Naian: But I guess over time when I actually look into
Naian: the code, then it'll make more sense. So right now the Aries we see, exports, the methods that I'll be calling there. That's foreign to me.
Naian: Yes.
Naian: and I dive into the code. Maybe it'll make more sense like we have to
Naian: back and forth with you all to understand how this works and stuff
Naian: I did have a session
Naian: of.
So last Friday
Naian: I had a session
with the Viruslav about the message. Create, I think. Yes.
yes, yes, so.
Naian: So we have the session about the message trade, and we discussed in lens
a mode. It and yes, some parts are quite complex. But yeah, I mean.
Naian: I'm getting a feeling for it now.
Naian: with time, I guess, looking into the concepts more and reading about it. I think it'll make more sense.
Naian: Yeah.
Patrik Stas: hmm, sounds good. That's that's great. Actually, now, as as you mentioned, like A, it's kind of a blur for you, as
Patrik Stas: brings me the reminds me of the idea from George Mohear, about creating, like Ellie's T or C, like Demo. And we just got freshly merged. Pr.
Patrik Stas: about like a kind of simple message related essentially like extremely simplistic. Maybe if we can even call it that way, it kind of serves
Patrik Stas: like ultimately councillors per post. But it's like a few lines of code, essentially but this will make it much simpler to create some sort of what kind of a
Patrik Stas: showcase of how a aresy 6 can be consume. So I think we can find now, like, address this and actually create some like simply a stable demo, and that I guess the earlier we do it.
Patrik Stas: Perhaps it, it can actually be a helpful for you as well. you know, I, I of starting the integration of as Dcx with the naviator code
Naian: all right. So look in.
Naian: Yeah.
Patrik Stas: thank you. Thank you for update. We don't have socknowled so, and me neither. George, so I'll I'll
Patrik Stas: I'll skip over this one. I can. I'm not really in position right now to cover it, but I just know that there is a Pr. For a while, and it's been progressing somewhat
Patrik Stas: there in some comments, so we'll see how this goes. all right. So
Patrik Stas: to back to the more mundane part of the a meeting. so we had a really 0 57. recently.
Patrik Stas: yesterday. you had to have to adjust this change like this autumn generated. But
Patrik Stas: it can be a pretty fight and structured. So we'll do that. There's lots of stuff in went into that because we're gonna have release for a
Patrik Stas: It was at least a month, maybe more.
Patrik Stas: So I'll I'll kind of make these nice during. It'll be easier to understand all the stuff fund in here.
Patrik Stas: Then we had the message really from George as mentioned before.
Patrik Stas: and lastly, that was a number of micro or like many fixes
Patrik Stas: some refactoring some
Patrik Stas: in terms of tells their entails file variable names
Patrik Stas: Then the removing unused Constance, and lastly, some Ci fix
Patrik Stas: Then in progress. We have a
Patrik Stas: kind of well, rather not not really in progress right now. We have post credits to an on credit migration.
Patrik Stas: We have. Pr for it. but it's more of a draft. Just a reference point for the future. and we pause. This we we we need to get good
Patrik Stas: clear up some things about
Patrik Stas: intentions of an on threads and the and a plan just to make sure that our plan and our approach is is right.
Patrik Stas: I know, George. Bogan, do you want to drop any any more words on on this topic.
Bogdan Mircea: Yeah, I don't know. I guess we've been discussing about this but length, but overall
Bogdan Mircea: with the outline, it's pretty much about
Bogdan Mircea: kind of getting a better understanding of what the plans are regarding all the underlying libraries, and
Bogdan Mircea: how to align, or even maybe shape them
Bogdan Mircea: ourselves, or help with that
Bogdan Mircea: and also our line. I'll align our goals and approach
Bogdan Mircea: to to better fit into that, because we haven't really done that so far. And this kind of biting. It is biting us in the back, so the the sooner it better.
Bogdan Mircea: Kinda kind of thing.
Patrik Stas: Yeah. all right. next up the Dixon's protocol is, Well, it's simply progress still. so lots of back and forth.
Patrik Stas: I think last we got mirror it was he he said, that I got some
Patrik Stas: that's passing, but he's is not satisfied with the implementation. So he's kind of reiterating and trying to find that but better ways before he kind of pushes it out there into ether publicly. So is this still in progress?
Patrik Stas: next up? I personally have a and other small Pr to clean up some discrepancies about tales. Do you like still file variables in the issues code that might be actually breaking change like a breaking change, but without the lunch impact, I believe.
Patrik Stas: and lastly,
Patrik Stas: bogged down started Vdr tools. Critics world migration like a a I think the Api to the Nodejs
Patrik Stas: is, is that is that we have a pr for it? But those some comments is it? Is it in progress, or, are we?
Bogdan Mircea: Since yesterday? It's just the those tests that have intermittent fails.
Bogdan Mircea: the the building was they're not related to the test or anything like that. So I added the test for
the the rapper
Bogdan Mircea: or the function exposed through the wrapper, and it all seems to work fine so it can mean it can be reviewed and even marched, should be should be in order.
Okay, cool.
Patrik Stas: All right. Upcoming work. We have the Cli demo. We want to do the seal. I don't know. I think if we do it as soon as possible, it can kind of accelerate 9 for sure with the the mediator. Or is this integration
Patrik Stas: the state pattern? I mean, I think I should remove that. It's like all topic we all know this is happening. We are doing it and did exchange.
Patrik Stas: we are gonna do it in other protocols. But technically, it's still upcoming. Okay? And it inspection updates. that's actually in progress on when I move this item, because Meadow is busy with that, he is a first step as a as a part of integrating and implementing the exchange it found it useful to
Patrik Stas: basically start testing with testing that did the exchange implementation against occupy and other implementations right away. So, but the first step to even be able to do that or so to update A or G 6 version in the adh, so I believe this is done. And now it's on a stage of like adding
Patrik Stas: the support for did exchange into the at H back channel kind of in a parallel with actually implementing the exchange.
Patrik Stas: And yeah, then we have the coming to the end meeting discussions. And this items and from both down. So I I'll leave it to you to to moderate, or what you wanted to have say about these.
Bogdan Mircea: Yeah. So Since that the the migrators for the exposing it through the Nodejs was done is they started working on the getting kind of getting the connection protocol up to speed with the
Bogdan Mircea: let's say, the design choices that we've made regarding State machines. so the connection with protocol was pretty much the first and only so far to implement the type State pattern, and
Bogdan Mircea: we further it rate on that to kind of change the States from sending a message to just generating the message and leaving it up to the user to do that.
Bogdan Mircea: and I believe mirror is basically shaping the did exchange state machine protocol implementation to
Bogdan Mircea: fit that design. There's George's Pr on, Holder. It's kind of being stayed for a while. But anyway, he started, and in that fashion as well. And yeah, I kind of wanted to get some hands on experience with this and kind of see the challenges and
Bogdan Mircea: all that
Bogdan Mircea: and the main thing that I guess represents a
Bogdan Mircea: I don't know where it poses. Some problems is what exactly should happen
Bogdan Mircea: from from consumers.
Bogdan Mircea: Customer of the library point of view with the outcome of the State machine, or how are they supposed to even process it
Bogdan Mircea: so ultimately, regardless of the protocol and State machine? There are pretty much 3 things that can happen. You
Bogdan Mircea: like, you get a message, you locate your state machine and you want to process it. So once that processing starts. There are basically 3 possible outcomes. You either
Bogdan Mircea: everything, either. Everything works well and you get your new. You get the state machine to the new state.
Bogdan Mircea: or some things fail, and but that doesn't necessarily
Bogdan Mircea: terminate the the protocol. It's just. I know it could be requireable So you still have your state machine in your old state, and that's fine.
Bogdan Mircea: There are for directions that you can do based on that. But maybe send the problem report or not. I don't know that's debatable, and it's not necessarily the point here.
Bogdan Mircea: but the and the other. The third outcome is basically that I know some sort of fatal error occurred, and the
Bogdan Mircea: instance should be terminated completely and is not retrial. So it's basically success, the tribal
Bogdan Mircea: or like error, but with tribal and error. But fatal
Bogdan Mircea: And I've been thinking about like how to kind of
Bogdan Mircea: deal with this, because this is going to be sort of a universal thing. Now, obviously, for instance, the the connection protocol doesn't even have like a failure state. It doesn't terminate.
Bogdan Mircea: There is no fatal error that can technically occur.
Bogdan Mircea: but
Bogdan Mircea: I believe the this. This actually became a topic of discussion
Bogdan Mircea: when George started working on the holder implementation, which apparently does have some like failed states where the the
Bogdan Mircea: instance of the protocol is not supposed to be to be retried. So it should be terminated.
Bogdan Mircea: and nevertheless, it's it's a matter of how could we perhaps approach that
Bogdan Mircea: and a more organized and uniform fashion, since. having all these different outcomes like, if you take
Bogdan Mircea: a singular transition and consideration. The transition might be successful all the time, or it might be successful and
Bogdan Mircea: successful or retrial, or it might be successful or fatal, or it might be all 3, and having differences in these results that were these return types from the transition
Bogdan Mircea: can make it especially confusing for consumers of the library right? Because in the end, if you look at the ecosystem and the other implementations, and that's maybe something that I'll go that I want to talk about more in the regarding the second point, but they're more like batteries included, or there are more abstractions going on, so that consumers are not that concerned with the actual implementations, with the functionalities of the protocols and whatnot.
Bogdan Mircea: because, frankly, they don't even have to be like people generally just want an agent to work and just do its magic under the hood. Now, obviously having flexibility of
Bogdan Mircea: changing stuff around. To better suit your needs in your use cases is is a great thing.
Bogdan Mircea: but I'm certain that the majority of people just want a working thing. and
Bogdan Mircea: basically, as a consequence of that, when you have the all these transitions from all the protocols and all the state machines, and they
Bogdan Mircea: each kind of return a different thing that you have to handle differently because they're different.
Bogdan Mircea: it kind of makes things convoluted and complex and hard to keep track of and hard to understand
Bogdan Mircea: again, maybe not for us as developers. But we have to kind of consider the people that would be using this as well. So
Bogdan Mircea: I've been mainly thinking about the uniform approach of kind of a a uniform
Bogdan Mircea: yeah, uniform result, if you will, of the State machine
Bogdan Mircea: of a State machine transition. So regardless of the protocol and state machine and the state. It would basically return an enum with these variants. And there's also the the idea of what what should you do as a consumer. If you get an error in a transition, right?
Bogdan Mircea: I want to think about a second. I want to think about that a second, because
Bogdan Mircea: if you get an error in the state machine, especially given the type state pattern that we employ and
Bogdan Mircea: the fact that it's a consuming operation.
Bogdan Mircea: you cannot just error out and propagate your E. C.
Bogdan Mircea: Consider that if you get a successful transition you might want to update your state machine and your permanent storage or database for your cash or whatever. But you definitely need to do something based on that. So if you get a success, you need to do some stuff
Bogdan Mircea: if you get a retrial or I know a retrial outcome. So you get an error. But the outcome is triable. Now.
Bogdan Mircea: what we kind of want to do is return the old stay machine, as is
Bogdan Mircea: but that might also imply that
Bogdan Mircea: I don't. If you have some in-memory cache where you took the state machine out of you might want to put it back.
Bogdan Mircea: So again, you might want to do something based on that. Additionally, I know, if you have a a problem report that comes out of the state machine.
Bogdan Mircea: You might want to send that
Bogdan Mircea: So it's not just a matter of okay. I got an error. It's a result. I'm just going to use the question mark and throw this up the more technically down the stack
Bogdan Mircea: and then, if you if like. If the stay machine just terminates, you get a fatal er then again, you need to do some stuff. You might want to clean up the state machine instance from your permanent storage from your cache, because that's not supposed to exist anymore. There's not that much that you can do with it. You can definitely leave it there if you want, but
Bogdan Mircea: I assume people will generally just want to get rid of it.
Bogdan Mircea: So
Bogdan Mircea: nevertheless, there's stuff that you need to do in practically every case of this
Bogdan Mircea: and what that means is that
Bogdan Mircea: even if we
Bogdan Mircea: kind of consider just returning the result with some stuff. I'm not even sure that's like I I tend to believe that's not really
Bogdan Mircea: the
Bogdan Mircea: That's not really the the way to go about this. What did you write down? Assumption to remove state machine or failure? What was that?
Patrik Stas: yeah, i' my screen. it was just a personal note, just a minor remark, you know. yeah, yeah, can you please repeat your last sentence?
Bogdan Mircea: Yeah. So if if the transition like, if you encounter a fatal error, you might want to do something with that, but a different thing than what you would do with a recoverable error. Let's say
Bogdan Mircea: you know.
Bogdan Mircea: what what do you do. What do you want to do with that? It's absolutely up to the consumer, like whether they wanna just remove the state machine completely from all their storages, or I don't know log some intricate stuff based on what happened I don't know.
Bogdan Mircea: But you definitely want to do something, and the odds are that it's gonna be something different than what you would do from if you if you encountered the record of a recoverable error.
Bogdan Mircea: Hi! How are you? You. Do you think that's fair?
Patrik Stas: Yeah, it it. I think it's fair, and it makes sense.
Patrik Stas: yeah, I I I guess. So this is pointing towards like the may be pointing towards the kind of custom enum right kind of there will be a solution or implementation for this kind of idea.
Patrik Stas: right? I I guess that could work honestly. It's it's a speed. We don't have a mirror here as a he's a kind of a more more
Bogdan Mircea: in the bushes, like in in the in an active Warsaw about this topic right now. So like more opinions than me. this is still like just a discuss at the discussion level. Then, yeah, it would be. I mean, we'll definitely go and get him. If his opinion on this it would be, it would have been nice, and he was here. But I don't think it's that big of a deal right now. it. It makes
Patrik Stas: it it. It makes sense to me. It is on top of my head. I
Patrik Stas: I can't really tell. What are those who tribal, and what are those faithful error so honestly. Do you have any like? I don't. I know, I'm sure if you open the holders you hold their pull request
Bogdan Mircea: one that George was working on.
Bogdan Mircea: there's been discussion there about these things.
Bogdan Mircea: let me see if
Bogdan Mircea: okay
Patrik Stas: for this.
Bogdan Mircea: yeah. So when when the after the offer is received, and I guess the The request is sent.
Bogdan Mircea: apparently per the old Api. The State machine transition into failed or request sent. Now.
Patrik Stas: so so is it some comment I can find about this. Sorry. There's actually there are some diagrams that you need.
Patrik Stas: Maybe
Bogdan Mircea: that was on the top. Yeah. So I guess this would be an example of. you know. Fatal layer, I assume, because once you transition to the failed state, you're not supposed to do anything
Bogdan Mircea: by with that state machine anymore. or at least that was my understanding.
Oh, let's see, I'm a now I'm looking at this.
Patrik Stas: I'm almost confused because
Patrik Stas: this the diagram I did here. It looks like it's doing like, I O in the
Bogdan Mircea: yeah, this regard that that's not important. It's not necessarily about that.
Patrik Stas: This was before we we're discussing the aisle thing. It's a matter of yeah.
Bogdan Mircea: like an example of a I don't
Bogdan Mircea: final, but failed. State.
Patrik Stas: like we know ahead of time. Even if we do this multiple times, we'll never succeed right? Because it some like
Bogdan Mircea: maybe it's issue with the request itself, or something like that. So that would be like a fatal error, right? But then you could have stuff like, I don't know.
Bogdan Mircea: Ledger communication there.
Bogdan Mircea: where it's just a matter of networking a networking problem, and that can be by all means retrial. Right? So
Bogdan Mircea: But if we do like.
Patrik Stas: like, I assume that, like on the I/O like in the State machine would be. Hmm.
Patrik Stas: can I assume that it will be?
Patrik Stas: It's just an example. But yeah, but I think it's it's still important to like. I I I I understand. Like, what what could it be? Actually in practice? So like it. I think it wouldn't be. It wouldn't be sending like
Patrik Stas: response, because we are not doing that. I think it also wouldn't be ledger communication.
Patrik Stas: Technically, it could be wallets. That's like the kind of thing like if you want to make it. Really. I guess
Bogdan Mircea: communication
Patrik Stas: from the world can be I mean, that's the I I for me that does the type of I/O. We will still keep in state machines, and that can technically fail because it's I. Right? So that's the only actually case in my mind where, like retribal, or could technically be returned because you could not reach your wallet because it's my sequel database or something.
Patrik Stas: But I don't think any other cases, because everything else seems to be deterministic like, you got state, you got some into data, it works, or it doesn't work. The only the non-deterministic part is the wallet.
Patrik Stas: So that that could be like retrial error.
Bogdan Mircea: Right? So that's that's again an example of that. So
Bogdan Mircea: yeah, it's basically
Bogdan Mircea: like a matter of
Bogdan Mircea: kind of having the uniform approach for these
Bogdan Mircea: and
Bogdan Mircea: like the the thing with that
Bogdan Mircea: is that
Bogdan Mircea: it's
Bogdan Mircea: I know it's it's a nice thing to do. I kind of drafted something. It's by all means in a very early draft state.
Bogdan Mircea: But If I could share my screen, maybe.
Patrik Stas: Oh, I I mean what comes to my mind. Sorry just just a random thought is like having the retrial Eric gives us like option to actually.
Patrik Stas: yeah, gives us option to have I O in state machines
Patrik Stas: like, if we actually find out in during the implementation of full the verifier, or I don't know whatever features actually protocols gonna be that like, hmm! It's gonna it'll it'll be like really a lot more convenient like for the users. If
Patrik Stas: you know the ledger communication, some sort of did. Resolution was actually in the State mission based on the based on the message received.
Bogdan Mircea: Then we technically, yeah, the I/O inside and return reach travel error if I fails.
Bogdan Mircea: we what I I lost you for a second there. So
Bogdan Mircea: you were saying that it would be convenient for consumers if we had ledger interaction within the state machine.
Patrik Stas: Yeah. So I mean.
Patrik Stas: yeah. Yeah. So I'm just saying that, like having the retribal error gives us kind of a beg door, like a a, an option
Patrik Stas: to put an aisle into a state machine. If we deem it as a. Because if we don't have a tribal, then we.
Patrik Stas: if we don't have retribal, and we have I? O, then any I/O error will become like fatal or other. If everything is retrial, then even fatal errors are retrial. And it's like really stupid bad for consumers. Right? So either way, you kind of get a kind of a bad solution. But with the 3
Patrik Stas: 3 So we travel in London tribal, you can technically have I/O errors and no, I errors
Bogdan Mircea: exactly. Yeah. And there's basically maybe another simpler example. like, based on the thread id, you're supposed to verify that. Okay, the message that you got is
Bogdan Mircea: you know, on the threat idea of this protocol instance, and if it doesn't match, it's not necessarily the end of the world. There's nothing wrong with the state machine. You just got the wrong message, and that's their problem, not yours. You can maybe send problem, report or whatever. But
Bogdan Mircea: it's not
Bogdan Mircea: something that went wrong with the state machine.
Bogdan Mircea: or I don't know
Bogdan Mircea: Nevertheless. So
Bogdan Mircea: yeah, basically, we could have something like this.
Bogdan Mircea: which, like I said, it has the okay version which has the new state.
Bogdan Mircea: the fail variant that has the old state, and maybe a problem report or an error.
Bogdan Mircea: Let's not pick on this. Maybe we could have 4 variants instead, one that has a problem report and one that has an error.
Bogdan Mircea: and then the aborted or the fatal or whatever variant that basically has. Honestly, I'm not even sure if it has to have something. I'm I'm starting to doubt those failed States as well like, what are you even supposed to do with those?
Bogdan Mircea: there's not really that much that you can do. But let's assume that we have some failed States and State machines. So that's what you would get returned here.
Patrik Stas: I'll just drop a note here, you know, because I and that's it relates to the you know. Note in my
Bogdan Mircea: sublime, you were asking about
Patrik Stas: a road like that. It it seemed like you had the assumption that when the State Mission fails like, you will throw it away. But I think, General, that's not true, because you, on some sort of like book, you know, keeping track of what those happening in the even for mobile use cases you often want to have like kind of a list of events
Patrik Stas: and have actual name for it and and you would want to see like, you know, you felt to share credential or some something went wrong.
Patrik Stas: Things like that, and and on the back and slot likewise, like you know, as a as a is that you sure I want to know if I felt to issue 10 credentials. I want to keep on a trick of that. So just just just a note that I think those spells states my opinion, are important.
Bogdan Mircea: I'm not saying they're not important. But
Bogdan Mircea: the what I'm trying to get at is, are they important in the
Bogdan Mircea: context of the State machine
Bogdan Mircea: states? Or are they important? Just as some events that you keep track of.
Bogdan Mircea: because they're not the same thing. They that doesn't necessarily mean that
Bogdan Mircea: having, like you, might as well just get some sort of an error here, right? And that's an error of fatal error. And you know exactly what we're wrong. But without needing to. I don't know. Update your state machine or delete it, or whatever you want to do like
Bogdan Mircea: the
Bogdan Mircea: the bookkeeping doesn't necessarily mean that you have to maintain an instance of that State machine and the failed state
Bogdan Mircea: necessarily.
Patrik Stas: it can be then confusing, because you will have a State machine left in like non failed state. I know some like whatever requests send.
Bogdan Mircea: Yeah. Which is why I was saying you could basically delete that and just keep track of the like the event that the this whole protocol instance failed.
Bogdan Mircea: but not necessarily as part of the state machine.
Bogdan Mircea: Hmm, okay, let's let's maybe nevertheless, like, I, I also understand what you're saying, and it's not necessarily but like, even if you have like a failed state and maybe keep it.
Bogdan Mircea: I don't know. Together with the other States of the State machine, and you have some other bookkeeping job that maybe archives, old records, or something like that.
Bogdan Mircea: That also seems perfectly fine. Honestly.
Bogdan Mircea: it's it's not like there would be an an issue with that, and maybe I know in some regards it might even be clear. I don't know. So that's definitely a matter for debate. But the the bottom line that I was trying to get at is that you definitely want to have a distinction between these and these, and regardless of which variant you get, you want to do something with it
Bogdan Mircea: erez agmoni. Right? So if you have a failed state here. That means you still have to update your failed state like your state machine instance, in maybe your database, 100
Bogdan Mircea: or your cash, because the next time, otherwise, like you said, the State machine would remain, would remain in its old state like request sent, and then
Bogdan Mircea: you're not supposed to have it like that right?
Bogdan Mircea: I don't. Does that make sense?
Patrik Stas: Sorry you you you you're not supposed to have it have it like what?
Bogdan Mircea: So I I I was basically trying to get at that. Whatever variant you would get. You know, one of these variant that you get out of the state machine.
Bogdan Mircea: You have to do something with it. You don't just propagate it
Bogdan Mircea: someplace, else, you know, or you don't just propagate the or something else. You first need to do something with this.
Bogdan Mircea: whichever it is. So
Bogdan Mircea: if it's a success, you update the state machine. If it's a fatal error. Again, you need to update the state machine. So you said it to be in a failed state.
Bogdan Mircea: and if it's like retrial, then
Bogdan Mircea: you might want to do something with the old State. Maybe send a problem report, maybe log there, maybe do whatever you want to do.
Patrik Stas: Yeah.
Bogdan Mircea: right? Yeah. So that's kind of the
make me think about this?
Bogdan Mircea: I'm actually thinking that there's like this problem report where I'm maybe thinking of flattening this and just having 4 variants in here.
Bogdan Mircea: and the reason for that is
Bogdan Mircea: like, I think it should be our responsibility to generate. I know standard problem reports for things that we are aware, happened.
Bogdan Mircea: but not necessarily, or all errors result in a problem report. So
Bogdan Mircea: that's why I think it might be helpful to have a distinction like sometimes you will return the old State and a problem report that the consumer can decide to send or not.
Bogdan Mircea: or and in other cases you return the old state machine. So it's still a retrial error. But the error is not really meant to be a problem before like, if if the communication with the wallet fails. That's not a reason to send the problem report to the other part. It doesn't have anything to do with it.
Bogdan Mircea: Right?
Bogdan Mircea: yeah. So so that would be that. So you can consider maybe 4 variants here. just for the sake of flattening this
Bogdan Mircea: I'm wondering if a if you ever you know, with the failed state which I consider that's supposed to represent the kind of retribal error. Right?
Bogdan Mircea: Yeah. If you would actually ever send a problem report.
Patrik Stas: You know, when you get to retrial or kind of error, because dudes are tribal.
Patrik Stas: That means that some issue must have happened. You know, some issue must have happened like
Patrik Stas: on your end, like typically with the I as I as I meant I I feel like we could even I. I'm not sure it might might be not with the I/O if something happens with the I/O, that's not the other parties. Problem. Yeah. Yeah. But I feel like the real problem is will be 19. I don't know 100, or, if not 199 I/O errors. It just can't think of anything else in aisle
Patrik Stas: for retribal kind of ever
Bogdan Mircea: like I said, the thread id that doesn't match.
Patrik Stas: Hmm! But if it doesn't match, then
Bogdan Mircea: they
Patrik Stas: or how would
Patrik Stas: like it can be also your problem. You actually don't know. Maybe you just like did a bad job with like matching the correct seed machine. And now you're sending a problem record to, you know, maybe some someone else or like you. You you did that
Patrik Stas: just you you you you've wrote the buggy code on top of this, and you'll match the wrong State mission based on a message you received. I would try to process the the message with the statement, and you incorrectly found in your database, let's say, and now it throws like, Oh, no matching thread Id, and you send a problem report. But there'll be like, actually, you know, actually, it's just what ended up being kind of confusing, because
Bogdan Mircea: you have to do something with it. I don't know if this is the only case. But I'm certain that there are a lot of instances where you're supposed to kind of send the problem report
Bogdan Mircea: without necessarily meaning that
Bogdan Mircea: your protocol is terminated like, Okay, yeah, your use case is valid. But I I then it might well be the other use case where the other party sent the wrong message and you send them a problem report so they can be aware of the problem
Bogdan Mircea: or I don't.
Patrik Stas: Well, I think once the problem report is sent like it's it's it's
Patrik Stas: I don't think those I I haven't seen protocol, which is kind of like, have this kind of
Patrik Stas: oh, recovery kind of stuff in it, or like it. It. It sounds like I mean, it sounds great, like very robust, but I don't think the actually in Aries community right now, there's
Patrik Stas: this kind of
Patrik Stas: you know, even in the on the Rfc level, typically, when the problem re report is sent.
Patrik Stas: Then you switched state some sort of failed state, and it's kind of the end
Bogdan Mircea: I'm looking right now with the credential issues. 1 point. Oh.
Bogdan Mircea: hold on
Bogdan Mircea: for these diagrams.
Patrik Stas: And well, actually, you know, in those diagrams, they don't really even like I mentioned the unexpected conditions like, there's a problems report like taking a place there. They are mentioned in the issue credentials, 0 0 36, for example. But if you get a nonsense, they they didn't like draw in the diagram the kind of cases which cases like, if you get a nonsense message, you send a problem report. You know.
Bogdan Mircea: I mean, they said something like if an issue might offer a credential for a price that the holder is unwilling to pay.
Bogdan Mircea: All errors are modeled with the problem. Report message easy to anticipate errors. We set the flow.
Bogdan Mircea: I think I'm still showing my screen. Atlanta. Okay, let me maybe bring this out here.
Patrik Stas: Hmm.
Bogdan Mircea: all right.
Bogdan Mircea: insurance abandoned.
Bogdan Mircea: So does that mean that
Bogdan Mircea: hmm. okay. well. sure enough, so
Bogdan Mircea: we could argue that, then there's like, if you get a retrial, or there's not even a a, a problem report to send. You might want to send a problem report if
Bogdan Mircea: you get to that completely failed state.
Patrik Stas: Yeah, I I think so because you receive bad input, right? And you want to tell them all, okay, if you send me like.
Bogdan Mircea: fair enough. Yeah, it does make sense.
Bogdan Mircea: okay?
Bogdan Mircea: So
Bogdan Mircea: I guess then in that case it would be something like, I don't know. Maybe this error, and then maybe
Bogdan Mircea: and then
Bogdan Mircea: I don't know. maybe an option problem report and this is a generic here because the connection protocol uses a different problem report
Bogdan Mircea: and you might not necessarily generate the problem. We port out of this. So I guess, having it as an option is a good idea.
Bogdan Mircea: okay. So so there's that.
Bogdan Mircea: yeah, that's basically the the overall idea of this
Bogdan Mircea: and I think that would make it
Bogdan Mircea: it would. It would come with less cognitive complexity. Because
Bogdan Mircea: and all these cases like
Bogdan Mircea: these things can. These are the things that can happen out of the state machine, of any state machine, of any protocol. Right? So
Bogdan Mircea: whatever you like, whatever you're doing, or whatever protocol you're in, or state machine or in or whatever message you're processing. These are pretty much the outcomes that you're gonna be facing.
Bogdan Mircea: I think it makes it
Bogdan Mircea: easier for consumers, especially to kind of a reason with what they need to do
Bogdan Mircea: based on the outcome as well as kind of making them do something with the outcome and not not just getting a there. And okay, I'm just gonna question, mark that. And
Bogdan Mircea: this is this, is it?
Patrik Stas: Yeah, yeah, that I mean, it sounds good. Now, let's
Patrik Stas: Sync up with mirror. And like you kind of what do you think about this? What? What kind of he also? I I I know. I remember he also has some sort of State mission result kind of structure, you know.
Bogdan Mircea: I don't. I don't remember exactly what it looks like, so we can kind of compare it and discuss for it.
Bogdan Mircea: Yeah. And maybe we can discuss a bit about the the other topic. and essentially, I'm I'm thinking about. I've been thinking since the the discussion yesterday about the fact that
Bogdan Mircea: we are kind of making a library, whereas the other people are making a framework.
Bogdan Mircea: and
Bogdan Mircea: when you think about it.
Bogdan Mircea: I think it might be there might be a fairly good reason why everybody else is making a framework and not a library. And I think it's because essentially, there are quite a limited amount of what's called the moving parts.
Bogdan Mircea: And
Bogdan Mircea: and all these and all this Aries ecosystem, I guess, like, okay, there are the protocol specifications. So the Protocols are kind of supposed to behave like whatever language you implement them. There's practically supposed to behave the way
Bogdan Mircea: they are described there.
Bogdan Mircea: like the moving parts, would ultimately be. Maybe the ledger, the wallet
Bogdan Mircea: the storage for the state machines.
Bogdan Mircea: and whatever mechanism you use to receive and send a message. But apart from that.
Bogdan Mircea: I don't really think there are other things that are. Let's say
Bogdan Mircea: that there there were even be a reason to have to deal with other things. Apart from that.
Bogdan Mircea: maybe there is more, but nevertheless it it. I think they are ultimately a limited amount of things.
Bogdan Mircea: so because I was thinking of, okay, this would be a uniform approach, and it would be
Bogdan Mircea: of a less cognitive effort to to consumers.
Bogdan Mircea: But
Bogdan Mircea: ultimately, what if we could even make this
Bogdan Mircea: less of a call for for users?
Patrik Stas: I I think this is definitely something
Patrik Stas: I think this was also made us concern, and like why he's so, you know he's coming back and forth. He's not satisfied, because I I feel like he find it too complicated. He he invented some sort of
Patrik Stas: like small, helpful air on top of the State machine to make it easier for the consumers.
Patrik Stas: But then, at the same time he did that. He didn't like the kind of you know inconsistency in the approach, like now, there's not like something new, something extra on top of that.
Patrik Stas: It's a just a symmetry. It's not beautiful. and what you're saying, like, you know about library is a framework. Yeah, I think you're right. Maybe we'll eventually make a full per call, cause like we came from framework where you know we did like
Patrik Stas: it was like super convey the you know the levy Cx is like it's supposed to be the original. It's it's supposed to be like it handled agency for you. It, like.
Patrik Stas: you know, couple of the connection protocol with the agents you really didn't have to like. Think about some of integrating them. You didn't have to deal with like fetching the messages and stuff like that.
Patrik Stas: But then, at the end of the day, we actually wanted to have that like kind of extra control. So we had to start like taking dial, start downloading a messages ourselves and then putting in manually to connection, you know, to connection State mission stuff like that, and that was desirable, because, like on the upper layers, we kind of needed that extra control to
Bogdan Mircea: for for reasons to him. And but I honestly, don't think that's what makes the framework honestly right now, the difference between like, there's actually a kind of
Bogdan Mircea: small and well-defined difference between us as a library, and
Bogdan Mircea: there is Vcx as a framework, and that's particularly these
Bogdan Mircea: I don't know. These are called state machines that consumers would have to deal with.
Bogdan Mircea: and all these possible states, and all these possible results, and whatever?
Because ultimately, like a framework like a library used in whatever way you want, a framework.
Bogdan Mircea: does a well-defined thing with pluggable components right? And there's already we we already kind of have the plugable components pretty well defined like I said the ledger. The wallet. stuff like that that you can just provide yourself as a consumer.
Bogdan Mircea: The only thing that's really standing between the the current state of the art, and and a more
Bogdan Mircea: and a consumer-friendly approach? Or are these state machines and their complexity? But when you come to think about it like I like I was saying for I'm sure that
Bogdan Mircea: most of the people that use this right now have used it, and we'll use it in the future.
Patrik Stas: They will just want to think to work.
Bogdan Mircea: And that kind of brings me to maybe having some sort of interface for handling messages, and it kind of ties to the way the messages create has been designed a bit.
Bogdan Mircea: and it actually makes the state machines. it might end up making the same machine simpler, so
Bogdan Mircea: kind of stick with me here a bit, but and it it might take a bit longer, so I don't know if you guys have time. If now, we can maybe discuss this next week. Okay.
Bogdan Mircea: So
Bogdan Mircea: the the the over lifetime of
Bogdan Mircea: of a message right would be, you get the message?
Bogdan Mircea: and then
Bogdan Mircea: I don't know you.
Bogdan Mircea: You might want to. You need to kind of see what message it is and get a state machine that's associated to that.
Bogdan Mircea: I don't. That instance of the protocol that you got a message for. And if things match up, you basically, and you basically try to process. Sorry to process the message right? and what that would mean is basically that
Bogdan Mircea: you would have these message handlers that expect a particular message and a particular state machine. And given the fact that we use the type state pattern, the state machine would be in a particular state.
Bogdan Mircea: So
Bogdan Mircea: you basically put these things in. And that's where your messaging process. Yeah, your your message processing starts and we can actually separate. Remember how we were talking about the I O being in the state machine. And that's kind of messing things up because the state machines are consuming. Well, what if you actually could do the I O in here, but outside of the in transition and the State machine machine transition would pretty much become infallible.
Bogdan Mircea: because you first try to gather all the pieces that you need to get to the next state. If that fails, you never even touch the state machine right? So there's no need to basically take it out and put it back, or return the old state, or do whatever you need to do.
Bogdan Mircea: like this whole. This whole thing was would essentially just
Bogdan Mircea: not happen.
Bogdan Mircea: because all the all the I and all the failures that can occur essentially
Bogdan Mircea: happen, a layer on top of the state machine
Bogdan Mircea: and the state machine would basically be there just to keep track of, like where we are in the protocol, which in the end, that's what state machines are for?
Bogdan Mircea: Yeah. So now the beauty of this, in a way, would be, we can provide sort of like default built in implementations of of these message handlers for all the messages that we.
Bogdan Mircea: you know, support
Bogdan Mircea: all the States of the State machines which we will ultimately do anyway, will we just incorporate that in the state machine itself. But people could maybe also provide their own like, if you want to override or just use something else
Bogdan Mircea: for a particular message, or you might wanna, I don't know. Process decorators differently or something like that. Then you could provide your own implementation and just not use the one
Bogdan Mircea: from the framework or the library, whatever you want to call it.
Bogdan Mircea: And this would even abstract away all this stuff in in in a way, because I'm thinking that if we go to this.
Bogdan Mircea: if you go, if we go this route to simplify things, we could even have this kind of state machine handler.
Bogdan Mircea: The interface of this is debatable again. This removed thing was maybe in the I know, considering the fact that you might want to remove a failed state machine. But this can
Bogdan Mircea: just as well go away. And what do you do? You just insert it with the failed state. And if the user wants to do something with that and remove it. They can do it later on. It's their problem.
Bogdan Mircea: but basically, given this this handler in this process. We just
Bogdan Mircea: take the state like we try to process the pieces before
Bogdan Mircea: the pieces needed to transition the state machine, and then we get it.
Bogdan Mircea: and then we insert it and
Bogdan Mircea: decide what to do, what to do later on. Now, this is not a final, obviously, just I I literally thought of this this morning. So there's a lot of things to figure out like what to do with. I know problem reports and stuff like that. It's
Bogdan Mircea: still needs to be thought of.
Bogdan Mircea: But ultimately, what this would lead up to is that when you get a message.
Bogdan Mircea: okay, you got a match on it to kind of. See. Okay what this message is and what you're supposed to do with it. But then you just pass in the message handler. You already have the message right? Because you matched on it.
Bogdan Mircea: You provide a state machine handler that will give you a state machine a particular state.
Bogdan Mircea: You might want to provide the I don't know. It's the one that will take you to state machine out of whatever storage or cache you have, and the one that's going to put it back. And we need an as an extraction. We need an abstraction over there because
Bogdan Mircea: the state machines, like each individual individual State machine and each individual state has a different type. So
Bogdan Mircea: it will be best to kind of have that outside. Now here, this is a basically the Id. I don't know if we necessarily need it to be generic, we might just use string. We might not. I don't know
Bogdan Mircea: But
Bogdan Mircea: ultimately, ultimately the idea is that
Bogdan Mircea: we can handle through this interface. The State machine handler we can take care of.
Bogdan Mircea: you know, depending on the outcome of the State machine, whether you get the new or the old one we can handle putting it just putting it back. You know, we can get it in the old State. We have all the pieces.
Bogdan Mircea: we transition it. And then we put it back.
Patrik Stas: There's there's one more yeah, it's it's interesting idea. I mean, typically, I would just need to. you got a message. the State mission handler.
Patrik Stas: And so that's style machine handler. However, it needs to. based on the message it needs to find that message in whatever storage it's stored.
Patrik Stas: I need to find a state machine based on the message that can be sometimes based on the message Id sometimes can be based on thread id, sometimes. Maybe I I guess there, there might be few cases.
Patrik Stas: Okay, let's see. So it it finds the message. It needs to understand the store. It needs to understand how the state machines are stored in that store.
Bogdan Mircea: right? Which is what this handler is for
Patrik Stas: and save it. But okay, I I see, like, maybe 2 kind of problems. First, is that
Patrik Stas: my schedule?
Patrik Stas: There might be bit of a like inefficiency like, since this is doing like stuff for you.
Patrik Stas: Okay.
Patrik Stas: like, First of all.
Bogdan Mircea: sorry, I'm just quiet. And this is all to take in. And you definitely need to think about it and
Bogdan Mircea: complete. So you'll need other pieces here. You might need, I know, a ledger type or wallet type, some stuff like that. So there are other pieces that are needed. But the point.
Bogdan Mircea: yeah, go ahead.
Patrik Stas: like, I guess the main thing I'm like, I think I'm considering is
Patrik Stas: a users like might have like different
Patrik Stas: like, you might want to have more data associated with the State machine, for example, than just the State mission. So like you want to. Maybe do some, you know, since, especially since we have this the of like, you shouldn't care about what to realize.
Patrik Stas: You know what serialize state machine looks like. Then, if you want to, for example, keep a you know, like some database of this, I know.
Patrik Stas: prove our state machines, and you want to track for each of them like number of attributes like, was it verified? what does the values provide it? And you know. Maybe you want to have indices on this field, so we can like do for filtering and searches and stuff like that. Then
Patrik Stas: then I'm worried like like the this gonna dictate too much.
Patrik Stas: If the State mission handler this, this could get in search thing is not gonna dictate too much about how the you know the database schema, or you know Mongo collection, or whatever must look like
Patrik Stas: And I guess there's like some
Patrik Stas: sorry.
Bogdan Mircea: Why would it?
Bogdan Mircea: it's it's still a trade. You implement this on a type. And you could have, you could store whatever you wanted to type. And you can design the methods to look exactly like you want, like you don't necessarily. You were talking about, you know, storing some other metadata.
Bogdan Mircea: If you could do that in this exact same method. Now, again, probably these are going to be asing trades as well. I literally just drive to this. So
Bogdan Mircea: I I I can imagine, like this being like,
Patrik Stas: convenient. Yeah, when you're staying in a rust you call system really like you're writing on top of this in R. That must be great.
Patrik Stas: or at least could be great.
Patrik Stas: I wonder I I I see that they will be like a lot more difficult to work with. kinda
Patrik Stas: and we're work with. If you go through. If a file, let's see. You know you have a layers between. No J in Javascript. and
Patrik Stas: then you have some like database handling inside. R. But then maybe you have some own, you know, in Javascript as well. It's kind of what you know what's happening. And and but yeah, okay, like, anyway, long term, like, kind of first classes, citizen is the rest. And we are planning to like, you know, a long term if you want to ride like if you're very far in the.
Patrik Stas: So this could be like pretty cool. But if this is like some, if it is like the handler. This stuff becomes kind of like, you know, literally like, this is a Dcx. And and
Patrik Stas: then I'm thinking also. Then, yeah, it wouldn't be great, for if I, and especially since lots of people are coming from from the Mobile, I wonder who how this kind of
Patrik Stas: you know how these would play with them. I don't know how they typically store the state machines. I think I think maybe sure would have some interesting in in assault on this. I I wonder what he would think, how how convenient, from his perspective or inconvenient. I don't know. Would it be you have this kind of handler, and, you know, kind of
Patrik Stas: deal with persistence on the on on that level. May, because I'm thinking, like, maybe you know, maybe when George is working with state machines. Maybe he's putting into some kind of Ios store, you know.
Patrik Stas: If he's if he's doing that from like upper levers somewhere, he gets a he's a message. He's the state machine. And then he puts it into some sort of you know Ios system store, and we don't want to deal with.
Bogdan Mircea: I I don't know. I I imagine we I I don't know what to support for, like Ios stuff, you know, from Rus. If you can even do that if you would even be able to write it. Kind of handle for a bit for a bit, and I can give you the example of the Cx. so that's what we don't live. The Cx. If I could find it.
Bogdan Mircea: it's somewhere around here the on the core, right? So in in let me seex right now, what is it? Handle connection? Okay.
Bogdan Mircea: in the v, 6, what you actually have is you have these, this cache where you store your objects, and I believe,
Bogdan Mircea: there were some functions for serializing. And this realizing right stay machine
Bogdan Mircea: that that could be your state machine handling.
Bogdan Mircea: You don't necessarily have to store this in the database if you don't want to. Some type which has some other methods that that look like these, you know, basically copy. Paste these into your type.
Bogdan Mircea: You expose them to ffi, if you want.
Bogdan Mircea: and that's it. And you do whatever you want in the I I don't think this is not flexible enough. I think this is actually. you know, very flexible. And even the message handler. You can write your own. If you have a particular use case
Bogdan Mircea: and just process. But then you you, it's basically a conscious decision that you make that you know what this. The the implementation that these guys provide is not suitable for me, and I want to do some other crazy stuff
Bogdan Mircea: with with the message or whatever.
Bogdan Mircea: and that's your business.
Bogdan Mircea: But
like, I said, if you think about it
Bogdan Mircea: ultimately, what most people will do is they're gonna match on the message and
Bogdan Mircea: and then do the whatever state machine transition, and then handle this result. And what else needs to be done like it's in in. I don't know. Maybe 100
Bogdan Mircea: erez agmoni, 90 out of 100 repository. That would be repositories that would be implementing our library. They would all do this exact same thing which we could abstract away make their lives easier. And also one.
Bogdan Mircea: you know, because for us it's easy to deal with with this kind of thing. We're the developers. We know what it means. But consumers, I can guarantee you. They're going to ask about it a lot.
Patrik Stas: Okay? Oh, maybe let's let's not stretch it off for too long. I I feel like this could be a lot longer. But let's also get like George on this. And then.
Patrik Stas: like, I like my just my May comes from. It's like, maybe people want to do like storage and resistance from their respective domain, whether it's in like Java or dials word node is, or or maybe I I don't know
Patrik Stas: that that's my concern. And maybe then, second second concern is like, actually And and what's yeah. Those could be another, I guess, like, for for discussion with a another thought is like possible complication is like
Patrik Stas: when you get the message. Typically like you passed that message to the State machine
Bogdan Mircea: and then, based on
Patrik Stas: if, like the processing somewhat completed, you know, you know you. You once you know that the message has been processed by a state mission and you got some result.
Patrik Stas: Then you want to, you know, using a pickup protocol, this kind of stuff. You want to update the mediator that you know you want to update the step status of the message that you don't want to no longer process it in his that has been processed. So maybe that will also have to be kind of considered and thought of.
Patrik Stas: If that can be abstracted away, or you know, how can we? Or how can we
Patrik Stas: support it?
Bogdan Mircea: but I think that can basically also happen outside of this.
Bogdan Mircea: So
Bogdan Mircea: I don't know, like you could, probably, and we're most likely you would return some sort of a result here.
Bogdan Mircea: So if you got in there.
Bogdan Mircea: you might not want to update the whatever the message in the
Patrik Stas: in the mediator. But if you did get an okay or whatever, then you can update it and say that it's processed
Patrik Stas: like, you know, that you didn't succeed. The state machine stayed in the previous state. But you just want to, and you will need to, like, you know, get a message again.
Bogdan Mircea: Yeah, that's that's a good point. I think I actually thought about that. But it's my mind. Yeah, you probably want kind of the same thing in here.
Bogdan Mircea: But without dealing with the state machine. Right? So you just want to. Okay, this is retrial. You can. You can retry later. And this is the error, or it's aborted. And
Bogdan Mircea: you know.
Bogdan Mircea: or it's okay, like, the the message was processed successfully.
Patrik Stas: so it could be something like that.
Bogdan Mircea: and it will actually make sense, especially in in the use case you provided
Patrik Stas: I think it's a very good point.
Bogdan Mircea: But nevertheless, like, even if if and if you do something like that, I think not. Having to deal with the State machine
Bogdan Mircea: is a big win for most of the consumers.
Patrik Stas: Well, I'll I'll I'll think about it. And yeah, I mean, I guess we well, let's think about it more I need to kind of get you through my mind, and and maybe take some time to process. That's a that's a good idea, though, and
Patrik Stas: I mean
Patrik Stas: I'm I'm I'm I'm I'm saying, like, you know, that we found out so as a library, which I think is the case at the moment
Patrik Stas: pretty much. But I I I can imagine, like having some like
Patrik Stas: right there, a thing layer on top of like this, like the these like library components, we have state machines
Patrik Stas: to like offload something, and then
Patrik Stas: that could be like easier to use. But at the same time there will be still those like granular components underneath that if somebody may. And what I, what I'm trying to get at is that then we can basically design the state machine is in a simpler fashion.
Bogdan Mircea: you know, with the like completely
Bogdan Mircea: without I/O, because we would do them here. And people would also have an example like, you know, maybe more seasons, developers that want to do stuff their own way. They would also have an example of what they need to do and how it needs to look like, and how it works to kind of do it themselves if they want to.
Bogdan Mircea: and I know they want to have have no handlers.
Bogdan Mircea: like I. I don't think it's necessarily taking power out of people's hands, but as much as enabling them to kind of get things working
Bogdan Mircea: faster.
Bogdan Mircea: and also kind of making our whole code much easier to to reason with, because the state machines right now do a lot of things, and that it's kind of painful.
Bogdan Mircea: whereas here we have the possibility of kind of layering things out in a much easier to follow away.
Bogdan Mircea: and a much organized matter of dealing with the state machines as well.
Patrik Stas: Hmm.
Patrik Stas: oh, yeah, that I mean the I/O must be somewhere. It's not. Is is the I of
Bogdan Mircea: yeah, no, it would be here. But this doesn't necessarily have anything to do with the state machine until it transitions itself. So where it transitions it. So, for instance, like I was saying here you would do whatever
Bogdan Mircea: I don't know. Take take any, any, any transition that you want, so
Bogdan Mircea: why can it fail? It can fail? Because I know
Bogdan Mircea: some some stuff just doesn't add up, or some I/O er, or whatever. Now, all these errors that can occur would be happening before you actually try to transition the State machine, the transition, the function on the state machine would only take the parameters it needs
Bogdan Mircea: and compose the next State. An infallible operation. But the the fallability is basically taken out
Bogdan Mircea: of the transitioning function, and into this, or maybe some other functions that this this thing calls. So then you no longer, I know. Return the old state, or whatever you do, and or transition to whatever it it's it's much easier to follow, I think.
Hmm.
Patrik Stas: yeah, you you might. You might have some point, and I mean, still it would. Still, that's a good point that you
Patrik Stas: so that you can still, for example, integrate this with with Vcx, which we want to keep the Nodej support, and just to message hand, or from technically just for B for the in-memory cache, and then you can do persistence in the database your whatever your own way.
Bogdan Mircea: right? And it's a difference also a thing to maybe note about this is that the handle like the state machine handler.
Bogdan Mircea: any any state machine handler can basically be passed in here because it it's a generic one, the function. And it's not an associated type like these things are. so if you just want to store your state machine differently.
Bogdan Mircea: feel free to do it. Like I, I actually believe this is something consumers would implement. We wouldn't implement something for them. So you might have a different database, or you might have whatever. So this is something that consumers would implement and just pass in here.
Bogdan Mircea: just as maybe the transport. Now this some.
Bogdan Mircea: There's also a matter of debate. I know we're kind of stretching, but whether given this this idea, we could still have maybe keep this transport trade and have them, or maybe just taking a closure
Bogdan Mircea: and also send messages or try to send messages from here.
Bogdan Mircea: or maybe problem reports. Only I don't know. And then people could still retry the message, sending afterwards
Bogdan Mircea: so kind of making things more
Bogdan Mircea: streamlined. I don't know this. It's we're stretching again, so there's a lot to discuss about this, but
Bogdan Mircea: I just wanted to kind of present the what I what I was thinking about
Bogdan Mircea: this would, sorry. Can you? Can you share it for back back for 2 more minutes.
Bogdan Mircea: Okay, sure, you get some loss
Patrik Stas: concludes and last thoughts. Just gonna that great do kind of a little brain dump on my my own. so there'll be the still mission and the message handle. It gets message because it's the handler handler can get message from somewhere story back there.
Patrik Stas: Okay, so, and we have, pretty much, we can share the same handler, for
Patrik Stas: I guess in pretty much the same handle for many different State machines, maybe different configurations.
Patrik Stas: So I want to store different state machines and
Patrik Stas: different tables or collections or files, whatever.
Patrik Stas: And then you get a message. You you process that. And this thing
Patrik Stas: you you get the let's say you get the what's interesting message. We got a connection. Request message you, you get the handler, for
Patrik Stas: we got a handle of for connections.
Patrik Stas: basically for that type of message. You might not even expect to find anything, because somebody simply send you a connection with this out of blue.
Patrik Stas: So in that case you will actually in in that pro, in that
Patrik Stas: processing.
Patrik Stas: you will actually get something. But you would process the message.
Patrik Stas: create the state machine. It would insert the staying machine. You will have to. actually. you might actually. once I guess the in search.
Patrik Stas: the inserts. In that case
Patrik Stas: the inserts to actually like a return some sort of id and then process process, I guess. Should also kind of
Patrik Stas: propagated because it creates some new new new recording database. You want the caller about some control information about it?
Patrik Stas: So that'll be like actually interesting case.
Patrik Stas: But then what happens? Then? You get that request you in the processing message. Okay, so you create some placeholder state machine in initial state. It it's a connection, a request to
Patrik Stas: maybe have to resolve their did. Maybe it's somewhere on some ledger, or whatever they it can be pretty much anything. So you do the id resolution in the processing
Patrik Stas: you within the what? So this on some ledger I O, you.
Patrik Stas: create the keys in your wall at some what I O, and then, lastly, like, you, generate the response for this.
Patrik Stas: generate the response connection, response, message. You send it. You find that sending message fail because you are out of Internet connection. Temporarily.
Patrik Stas: you might have some, I guess, retrial logic. And
Patrik Stas: I guess the processor that's the kind of thing which would be probably conf configurable.
Bogdan Mircea: so
Bogdan Mircea: I'm sorry for interrupting. I think we can at best try to send it once, and people can try to resend it later on, like we're still gonna generate the message. That's it's still gonna be the way the State machines would be. So you generated the response to a connection request
Bogdan Mircea: you transition to state machine. It contains the response. We can try to send it once, but then people can also retrieve the state machine from the database themselves, maybe have some sort of background tasks that
Patrik Stas: I don't know if you didn't. If you don't get the response to your last reply for, or if it's stay machine being updated in 2 days, then maybe try to resent the message. If there is a message to resent
Patrik Stas: we would still keep that constraint of not doing like the send response I/O. In the process method. We would, only we could do it once, but we don't guarantee that they will actually, you know, do anything or like. I said the the thing with the the State machine states is that we? We can send the message, but we'll never have the confirmation that it was received
Bogdan Mircea: so
Patrik Stas: by all.
Bogdan Mircea: and we might have, like the the thing with having the ability to send messages here is that it might be convenient in the case that we get the a problem report that we
Bogdan Mircea: it might need it to be sent so we could give that to users.
Bogdan Mircea: Hmm, actually, you know what? That might be a better idea. Okay, maybe we don't do any message sending it all. Maybe we just give the resulting messages to the user. So
Bogdan Mircea: good point.
Patrik Stas: because then you would have to. If you. If there's like 2 outcomes of process like you get connection, request. And basically there's 2 outcomes like either the response or send or not send. Did I imagine, after after after calling process and use a call, I check what actually happened, which state I am, and if I'm not in the
Patrik Stas: you know
Patrik Stas: the I know state which signals
Patrik Stas: successful sending.
Patrik Stas: Then I have to kind of retry myself, possibly, or you trial nature, and that's kind of like complexity. So yeah, I think that
Bogdan Mircea: message sending out keep it out of the process
Patrik Stas: if you wanna make it responsible. So so in that case this would encapsulate the ledger.
Bogdan Mircea: And yeah, like getting the pieces.
Bogdan Mircea: Sorry.
Patrik Stas: Yeah. So this process method will basically encapsulate like database read and right of the state machine before and after. In the in the middle there'll be processing of the received message, possibly some sort of like a ledger like interactions, and and like, what interactions
Patrik Stas: generating?
Bogdan Mircea: Okay?
Patrik Stas: Yeah. And technically like, if you actually.
Patrik Stas: if you actually don't, yeah, if you want,
Patrik Stas: if you actually don't want.
Patrik Stas: you know, the message.
Patrik Stas: the the handler to deal with the database. You can always kind of provide really mock, come off state machine handler, which would
Patrik Stas: basically do nothing like just memory slot somewhere, and it would try to mess, get the state machine and write it, or just write it. If nothing was there. In the first place, which is also the case with the connection request for you don't actually have you received the message, but you don't have any state machine to load up here?
Bogdan Mircea: Right?
Patrik Stas: Yeah, this could maybe kind of like, provide that kind of uniform
Patrik Stas: layer on double state machine. This thing, that mirror was coming up with. But but it didn't seem uniform. And like, it seems like a symmetric. Maybe this could be that kind of a shared interface.
Bogdan Mircea: Yeah, definitely achieve it
Patrik Stas: for the I O, which needs to be done on top of the machines. Since we want to.
Bogdan Mircea: Yeah, I was thinking about the the framework. I think I think I mean in the end people would still have to do this themselves and match on the erase message and whatnot
Bogdan Mircea: But I just think like the the overall, like we can abstract away some stuff that are really common
Bogdan Mircea: are kind of our responsibility, and are not really something that
Bogdan Mircea: consumers should deal with, you know.
Bogdan Mircea: like the actual message processing while also making the whole interfaces nicer.
Bogdan Mircea: more about it. Maybe you know, also consider what you said and all the possible use cases.
Bogdan Mircea: Kind of drop the more completely. Api. But
Patrik Stas: yeah, let's let's leave it. That's this. And I think we have lots of next week or something. No, and I think, this will be this, this must be like a compulsory listening for for charge. And I met up
Patrik Stas: so they can do the inputs on this discussions. And and I think, like you are up to something and I think, like Middle also, like, I might also find some some parallels with the problems
Patrik Stas: he was struggling in this process.
Patrik Stas: a method which can, I would uniformly could potentially, uniformly encapsulate those.
Patrik Stas: The the complexity you want to extract out of state machines put them somewhere on top, and maybe this message hand with that layer
Bogdan Mircea: on the right.
Patrik Stas: Okay.
Bogdan Mircea: all right. That was that, was it, then.
Patrik Stas: And I think we have one more item in the agenda.
Patrik Stas: What's that?
Patrik Stas: No, no, no, I don't think so.
Patrik Stas: Good. Good.
Bogdan Mircea: full solar.
Patrik Stas: fortunately. Okay. So you guys are all free
Patrik Stas: man, hopefully, I don't know a at least like you. You took something out of this. I I don't know. You are listening actively. It might be kind of like
Patrik Stas: I mean.
Patrik Stas: confusing or like advance. We already have, like lots of context about what we are doing. And you're just kind of like meeting aer 6 initially. So hopefully, it was any, any, any, any any good and useful for you
Patrik Stas: as well?
Naian: yes.
Naian: it. It's sort of like passive learning, I guess.
Patrik Stas: Yeah, you like, just kinda like.
Patrik Stas: call, like the glimpse of like, kind of pattern here and there.
Naian: Yes.
Patrik Stas: yeah.
Patrik Stas: Okay, folks thank you very much for for bearing this really long call, and have a great day and wonderful weekends with this and coming.
Bogdan Mircea: So you know, Sam, thank you. Do have a good one. Bye.