I'm going to turn on the recording. All right, so. Well I mean we've got a let's get started. I mean, we, you know, public forum. Welcome back. You know, I'm still baby tighter but we got to go hiding. So let's see. So first of all, just keeping with the agenda. I wanted to do stand up so let's go around and just talk about each group's progress. So, let's see, Id do you want to give an update about what you're working on this week what your plans are for, you know what you got done last week, etc.
Max Can I Can I request you to pull that milestone deliverable sheet.
Okay, but that's kind of later in the agenda. Can we just do a quick brief stand up first. Just a quick status. If you don't mind. So, who wants to go Taylor. Yeah, Joe had a you know a more, okay, tailor, give us an update.
So we.
Last week, I guess, or since we met last our discussions are really focused on on Pub Sub. And you know how, how we're how we're fitting Pub Sub into information mediation or recognizing that it's really as a separate building block, that sort of plays by the same rules as all the other building blocks that use the information mediation layer. And so we have, you know, we're almost through this, this round of edits on the, on the IMDB spec, but recognizing that there's this big sort of outstanding question around Pub Sub and then whether it should be, sort of part of the IMS back or whether it should be lifted up and then the aim spec should sort of be finished. So that's, that sort of the biggest thing on our plate right now. And I imagine we'll get a chance to talk about that a little bit today, maybe.
Okay, great. Ingmar Do you want to give a brief update.
They can even share the screen I think we have enough time, just to
share. So, in the registries or digital registries building block, there was a request by Max and I think there was somebody else that maybe we should have also the API to, to create databases in the registry system. So, I created the user story, so did the it developer has, as an actor and can create database read database schema update database schema, and delete database and database schema. And we created those API API's. I'm going to go to the API section. There's database schema API's, there is a rich schema, modify and create and modify schema and delete schema, and also to see the database list. And today in the working group we discovered this one more ski, one more API we need to check the logs as well but the schema should be fine. And the document or the open API descriptions are in GitHub.
Great.
Choose two files, two descriptions one for data and one for schema. And I would like you to comment on those, we probably will do small, small changes but in general, there should be fine. Let's see if they go to this dictation. Then my, my kind of question is that, if I want to push them in contribute. I'm going to open a pull request, right. And then let's see what happens after this. Correct.
Yeah, definitely, um, I think that that'll be great I mean, then we can just review the API's, kind of more formally, and then provide feedback and then hopefully get them landed on the main master branch.
Good to see my screen at all. Yes, good to help I'm not sure,
I do see your screen. Yeah, we
could we could still see, not, not
right now, but I did, yes.
So you saw the GitHub as well alright yeah so, so that's pretty cool intent, we'll try to wrap up the document for for version 1.0 for this week. And then, then we're going to take the registration building block and fine tune that as well. Okay. Other than that, there's still some tasks to do, but in general, we're okay. Yep.
Okay, great. So John, do you want to give an update,
you're muted buddy. Yeah. Yeah, so when they said, No match was still on our specification. So we are going to present some use case where the currency suite, in order to agree or what is the next step. And so we agreed that we need to document more in documents or we have started to list all the capabilities that you cannot fortification. So this is ongoing work that we are doing a review when. And while waiting for an edge to be available so to ever look to to the other, identify students try to describe describe abilities functionality one two complete.
Okay,
great. All right, that's awesome. So it's always good to just start with that so I'll just give a quick update about architecture we've been mostly focusing on this rapid prototyping. So, doing, doing, doing a lot of reviews, still owe a bunch of feedback, I think, you know, particularly for registration or sorry registries and ID. But, you know, alongside that just working on coming up with a structure for, you know how we do these rapid prototyping with wireframes and demos. So that's pretty much it for, for the architecture group I it's been a little slow, apologies I caught a cold but I think I'm like, it's almost all, you know, it's, I'm almost rid of it. So, um, okay. So anybody have any questions, concerns, comments before we move on.
Yeah, I had a quick one, maybe.
Yeah,
more just a process question. I'm wondering what the wondering about the two different cross team stand up snapper. Yeah, I know they're, you know, sort of trying to keep trying to keep the time down on going around the horn and stuff like that. Yeah, but then on the other hand, and sort of like I'm in favor of it for that reason. Yeah. On the other hand, I think, a good argument against it would be that one of the main purposes of this meeting is to have sort of a representative from each group in the room, so people so that like when something is communicated it can be communicated once rather than being communicated in duplicate across the two meetings, I wanted to sort of hear if there are any thoughts on, like whether or not it would be a good idea to combine the two stand up to just have one cross team stand up. Or, you know what are the pros and cons, why are we doing it this way versus the other way, hoping to sort of just share thoughts on that real quick.
Okay, I mean, I've got a few thoughts. One is we're starting we're basically diving into use cases again. So we've already started that. And it just seemed like this group and kind of run out of patience for like going through user use cases and user journeys. But, you know the reason we're doing that is because there are a bunch of use cases that we didn't do because they're really obviously pointing to messaging, right, like both of the most part of movement care, and the unconditional Social Cash Transfer user journeys, start out with messaging, essentially, to promote the program. So we've started, you know, diving into that and it's, it's, So that's one reason. The other reason is it gives us more time to get the group's kind of on boarded and kind of in sync with this process in terms of you know which documents they're editing. You know what the overall scope is and where they should and they're kind of in the very beginning, like they're just starting to do the scoping exercises. Right, right. So, it just seemed like, I'm just in the interest of. There's a balance between having these separate meetings which is especially, you know, kind of annoying for you I guess cuz then you have two meetings, because you're doing information monitoring and workflow but versus, like, here we're kind of like more advanced, I would say right like so that was the initial thought but I'd be open to combining them, just for simplicity sake, But it just, you know, it's something that we should talk about because there's going to be, you know, a lot more q&a A lot more basic stuff and just like a lot more scoping and use case development.
Yeah, I'm with you, I'm with you. I want, I wonder if there's not sort of two things going on. One is like, you know, providing a chat for the new working groups to get guidance from RE architecture group, which is like one sort of walk one outcome that needs to be addressed and then the other outcome is like providing this forum for truly like, you know, cross team communication. And we're trying to like solve both of those things with the same meeting,
yeah, yeah, so, um, you know, provided that people are not completely turned off of doing the use cases in this meeting, I think there's a real value of doing the use cases with everybody from with representatives from all the groups. So if everybody's okay with that, I'd be, you know, once the, once we feel like people are on boarded. And actually there's like momentum, like they're meeting every week and stuff. And they have all the members that really you know, once they're spun up we could just do the that part of the meeting. In this you know in this call, basically and just invite all the groups I mean, I think there's a lot of value in that because the whole point of this is to eliminate duplication right within, and it's like a little bit hard to do that if we don't have representatives from each group at least occasionally they're right. As we've seen, right, so, um, you know like just last week we're talking about identification and how, you know there's a population registry, right, And so is that a, what does that have to do with registration building block for example like something nothing. If we don't have representative from both groups, it's difficult to nail that down right. So, any other thoughts folks have other thoughts I mean I mean I would be you know, to summarize, I would be on, I'd be into combining the cross, like inviting the other teams into this call, once they're on boarded. Just, and then you know that sort of a good compromise that allows, we don't we don't spend people's time, onboarding in these calls, because you're already on boarded, but then they once they're on boarded they could we can just get on
board and then we combine and that saves a little time in the sort of the double communication side.
Yeah I think so. I mean it's it's kind of like I think, you know you're right there are kind of like two mandates one is onboarding and getting people getting new groups up to speed and the second is like cross group collaboration which is really what this meeting is about right so I think we should combine them unless anybody has any objections.
Sounds good doctor after the onboarding. Okay,
onboarding process documents doctors, blah, blah. So which may be, you know maybe it's a lot of time for the rest of the group right now. Yeah, then it is not that the world use cases, you know, there were places in the world use cases where messaging was required for example, and other building blocks might also have things which, in the old user journeys that may have already done, they are endpoints which we are not tapping because those groups were not there. So, it is not that we have to take all new use cases. But even in the old use cases we are to explore what we left behind, that those guys have to pick up here, maybe that's besides to explore, explore,
I think so and I think it's gonna, you know, it might be annoying for some people who were just tired of the use cases but it's kind of necessary that we do it anyway, so. Okay, so let's do it. Great decision, great, great point Taylor, thank you for raising it. Anybody else have any other questions, concerns and comments. They want to raise.
See on, I think Max onboarding is something we can have a separate meeting, just for that sake, if required. This craft group meeting can have its own agenda like discussing now you can describe, we should definitely visit the user journey, even if the existing groups have gone through it, just because, for all these older groups, it's a sanity check now, whether we did everything that we thought.
Exactly, so we're gonna we're just gonna, we're gonna suck it up and go back and revisit the user journeys, you know. So, okay, cool. So, you know, related to that, um, you know, I do have sort of two separate project boards right to track the progress and synchronize that across groups so maybe we want to combine the project boards as well. Yeah. Yeah. Okay. Uh, okay, Cool, thanks for raising this again, tailor, anybody have anything else. In general, that they want to cover. Okay, great. I
didn't go over one thing that there is a table that some groups have started putting in their definition template Max I just want to visit that table and see if that can be absorbed into the general template that to have for billing.
For sure, yeah I mean, the difficulty is once somebody has made a copy of the building block definition template, it's hard to like merge changes back in but we should definitely keep updating it like I keep finding little issues in the work group, you know onboarding kind of cookbook document and I keep touching that up. I keep finding like little issues and kind of, so I would just encourage you to make those edits, so if there's a table missing from the template. going at it but make sure that everybody's using the new version of the template, right, the one that one right that has the numbered headings and all of that. Okay. So yeah, I mean, do you have a URL you'd like to show the group I mean I can pull it up on the screener, or an example document.
You could go to the root and I think you can pull it out, or you can just, okay, it's in a couple of groups have voted. You can take the payment building block group definition template, it's they have started on that. Id template has also started putting that,
yeah. Okay, so, so the payment, the building blocks spec. The most recent one. Okay, so let me just, I'll just turn on my screen sharing here, just to make it easier for folks. So we can all see the same thing. Alright so, which table are you talking about,
go down a bit, I can pull out there is a table which says mapping,
blah blah mapping based on level of maturity mapping. Okay.
No, I got these two things. One was the mapping of based on level of maturity because this was very useful because, although this document captures so many types of scenarios and so many types of, you know, modalities. Yeah, there was a kind of helper guideline that they're adding it says, Look, if your infrastructure is at this level, having this this this an infrastructure, then it's better that you use this modality of payment for, so it kind of Maps for mobile money what is the basic infrastructure components are required so they can cross check and say Oh, I'm not ready for mobile money, I'm ready only for vouchers. So anybody who sees this gets a picture of how to what capabilities of this building block makes sense to them.
So, so this would be for like somebody who's considering using the building block. Yeah, yeah, it seems like a little bit I mean, you know, it seems like a little bit early for this because, like the, remember that the reason we're writing these specs is to put them out for tender for development. So this is
that, yeah you can park it. But this, this, this, this table, the top table I mean, yeah, top table basically to kind of, as part of the recommendations that come along with the specifications.
Yes, it makes sense I mean it is policy related. Yeah. Okay, and then
it is basically a map from user journey use case, there are scenarios that they have quoted in this document, and to the capabilities that we are producing in those scenarios are relevant to those scenarios and modalities that they are actually building functionalities for, you know, in the spec, this is a overall table, which helps. They'll populate the links backward to those user journeys, etc, and forward to the sections in this document. So if you click here, in this scenario, there is an explanation there is a flow chart there is a probably a resource model that corresponds to a particular scenario and it will link to that.
Okay, well that's interesting. Okay, anybody have any questions or comments about that thoughts.
I mean, so Id team has started putting this this payments group has started putting Today we discussed within mark, and I think we need to discuss with the tailor and other groups as well.
Sure. Yeah, I mean, this is fine but you know I mean, I vote that we do this last, and just focus on getting the, like, you know, functional specifications like you know these early, you know,
yeah, yeah, but, like your index you know if you put at the top there, somewhere new, as they populate the thing, this is helping them navigate otherwise there's a lot of information here, and navigation becomes an issue with this is going to become very nice index
talk well it'll be great to see how, you know how it how that evolves. All right, well great, so I guess we're not really doing the PowerPoints for whatever you know, but we do have an upcoming meeting right don't we have like an upcoming monthly meeting. Yes. Can somebody remind me what yeah next week
we're, we're doing like a Tuesday. Yeah, we, I just assigned sort of PowerPoint update to the workflow group at our last last roundtable so I think, from, from my perspective, anyway I think we're still updating PowerPoints but yeah so just, we haven't done much on info mat in a while.
Yeah, yeah, so, you know, I mean, those are kind of handy The reason we're doing these PowerPoints, is it doesn't have to be a lot, I mean it could just be two slides right just a summary of where you're at, what's changed. You know how close you are to completion or you know whatever like it's it's it's just an executive summary, because it's really useful for, you know, the steering committee steering groups and other folks to, you know, quickly get an understanding. So if you can try to throw together, you know, a brief PowerPoint for next week's meeting. So reminder about that. You know, I, you know, as far as architecture I mean I can say like we don't have, you know, we got new presentations but they're not like this one so we're gonna have to work on it as well, so I haven't really touched those for a while. The monthly update ones. Um, okay, so. And just to give you an idea, like if you're curious. You know what, what we're talking about this, if you go in the architecture. You can see this you know, like, a. There's some PowerPoints in here I think. Yeah, so these like updates, June, July progress update. I guess we haven't done this for a while. But, you know, just to give you an idea of the scope, I mean it's just like, who are we, what are we focusing on, you know, what's the, you know progress we made and then what are outstanding issues like like that, you know, and then like maybe a big picture vision thing at the end if you have time, but you probably won't have time, because, you know, you'll get like three minutes, right so I wouldn't bother doing even this many slides but that's just an example of what we're kind of like the kind of deck that you should put together. So, probably too long, right. But you know you get the idea. Okay, so, just so we don't forget anything want to move through the agenda, reminder about using the building block definition template everyone knows that, you know, write down your significant changes and decisions in a log under a header in your building block definition template so you can see like the building block definition template 1.1 point oh, kind of has that. If you just, you know, follow this link, it'll take you right to what I mean. Or it used to. So I guess it's all the way down here, this key decision log here, so you guys are all doing that right a
bit hard thing to have the key decisions, meaning that whatever we're deciding that's going to go into the document.
What's that well it's just like, yeah, maybe like if you make a major change. Right. You know like we decided to add schema, you know, update API's, you could say like, we decided to do this on this date because, you know, like just put a sentence there, maybe. Okay, yeah. Okay, good for like big, Big changes right so just a reminder about that. Just so and the reason for this right is so that if other team members join the group later, they understand how you arrived at that decision, the decisions you've arrived at. Right, so to try to preserve a little bit of that history. You don't have to write down everything but just, yeah, great questions. Um, okay. Reminder to provide source for all images and diagrams, you know ideally drawn at i o your or web sequence diagrams that can be edited and evolved. Okay, so last week's key decisions registration for foundational ID is completely separate from registration for information mediator access. So, right. And then we're going to ship with consent management and distributed ID on by default, if we can, right, just like try to encourage good decisions. You know, and we also did talk about this, you know, point to point thing with the publish subscribe so we can talk about that revisit that. Right. So okay, so those are key decisions. So, now milestones checklist, right, so this is Ron from our, why don't you take it away. I'll give you the
check if all groups have updated this, if not, first thing is, let's get this updated because I want to take this snapshot for the, for the all hands meeting as well, because this is overall capture of the status, and is especially here one thing I saw. If there are issues, they are not captured here. This is just status milestones checklist, and if somebody is stuck somewhere, there's no column to add a few people feel that we should add that here we can add to that as well. But as, as I see here. Can we at least go through some of these as we see now and if there is something to be updated we at least know
okay what is pending. Oh, you know what though, before we do that, we've got folks from payments, sorry guys. Do you want to give us a brief update. Sorry, I want to get your stand up as well like what you're working on.
Yes. Yep maxisys payments. Regarding payments. We are now working on the API's specifications. So this section in the, in the payments building block where we talk about the API specifications, different type of payments for the CO payments, then for person to govern with payment. The voucher payments as well. So I think we've found the voucher payments, the API's. There's a lot of work has been done on at the level of the voucher API's. on this side. However on the bug payments, and also new we've, we've reached out to different organizations like Moodle. There's open GTP within the working group as well. And also with jsme as well for the mobile money API's to help them to contribute these to the documents. So, this is the part that's going to take some time. Because they mean we've explained to them, we've had a one to one meeting with each of these organizations. Over the past two weeks, to explain to them you know the use cases that we have and you know how to maybe also provide the API information with regard to these use cases or if any can be incorporated in the document so we, I think from jsme, we're having a meeting with them again next week for them to present the API's, as well. And for Mojo loop and open up we are waiting API documentation. Okay, it might take some time, maybe we'll get it first week of November, something like that. Okay. That's a bit the status and then we also refining a bit some of the document. We are getting also comments from the World Bank has sent on comments this week I saw this, by email, but we get to look into that. So the on the functional specifications but we were also making some. It's mainly I think refinements. Yeah, we are more, more or less ready on that. Okay.
Okay. Great. Awesome progress.
I think there's one thing we would like to mention, you know, when we talk about the beneficiary for the GTP payments, especially in the case of vouchers.
So is there some place I could pull up here in the document. That's your management maybe
what I don't think so it's related to registration basically, I see I see. Yeah, so you know when it comes to voucher management. We, we wanted to know, you know, the vouchers, it would be the vouchers are issued to the, to the person. It should be a voucher that's eligible to be used. Maybe a certain number of merchants. So we wanted to know whether the merchant registration is being captured at the level of the registration building block. That's important because the vouchers that are issued will be mainly for from would only be able to be used at vouch at merchants that are part of a GTP program, for example,
right. Okay, so that's a good thing. Just to make it understandable, because we're using information media to write mean that that's all controlled the O axis right to the merchant. The or the information that can get access to the API's. They're all managed by the building blocks themselves, right. The the authorization. There is done by the building blocks themselves so the merchant merchants are who they are, let's say registration building block is the merchant, in this case.
You know I think it's a little bit different I mean it's like you, if you're creating a voucher. You might want to when you're creating the voucher say like this voucher can only be redeemed at a grocery store, and provide an authorized list of grocery stores so you need a registry of, you know, locations, or, you know, voucher redemption partners. Right. And so I think what they're asking for is, is where who's going to Kin can registration provide that functionality somehow.
So yeah, maybe also you can also add some more information based on what Oscar was telling you as well for the workshop.
So the payments. Assume that the registry is available. Right.
This is the assumption we made about, we just need to make sure that it's exists.
Okay, so there is a registration building block right, but I think if you're going to depend on it, then we need to actually, you know, write out exactly what is being depended on for, and what the functionalities are
so I can build the registry, kind of services for for the merchants database but who's going to consume it.
What we don't is that you know you only get certain the people that are going to receive your funds, or people are going to go to certain schools and things like that. They also need to adjust, which schools they can go to in case we give them advice or say that okay yes you're qualified to get free education as ingestibles schools where they can actually redeem that kind of service, if they have to, or if it's cleanings and things like that. For instance, if you see that a mother. At the end of the month, or when they have to get medicines, they have to go to a particular pharmacy to get those medicines removed also reduce pharmacies where, You know, that are allowed for dangerous
free country, country call anything about this in the user stories.
Unfortunately it's not the user stories.
We found out when we were discussing with the voucher payment under redemption. This needs to be checked. Basically,
Mark, this, this is like, I think, you know, we were assuming that the nurse for example is already registered, when we got into that user journey is that okay nurses logging in. So, prior to that we were assuming nurse is already registered in the system. Likewise, these guys already registered for being able to work like a merchant merchants registered somewhere. So, as far as payment building block is concerned, they can, they can say this is a precondition for me I am assuming that there is a registry somewhere, which contains the list of merchants. Right, so whether that registry, where the that that really is lying around and being used by is dependent upon the implementation, some obligation which managers need commerce in the country, probably, which is neither payments, nor healthcare, but somebody else is managing all payments. Sorry, all my friends in the Venturi.
I was just thinking that it's extra complexity that we're gathering into our use case, which is, which was not written there. So, I could we could just say that whenever the role chair is issued, there's something printed on the vulture, that says where you can go and redeem the fee for it. So that's it,
I guess, in my then for us what we found as a question on our side is that if we do issue out vouchers, then how do we know that the right patient is actually issuing the status for that. Right. And if you put it in a practical sense or let's say in a country. If you give out a voucher, then you need to know where you can redeem that voucher. Otherwise, there are very many various points where people are purchasing service, and you probably don't work as a government program you probably not working. You're working just a few. And that comes back to the time of payment for instance, you'd have to pay those items, what digital services.
It's the same thing, meaning, whether you printed out on the voucher itself that you can redeem this in this location or that order there is a register where you can see the list of places where you can use the voucher, same thing. Alright, we can we can put it as a pre requirement that there is a register of merchants.
For the registration building.
Yes, I mean there's two ways to do this we can add a use case, right and formally write it out or we can put it as a precondition that this thing already exists,
because we, we will then get into defining a lot of details that we were then have to think about what is merchant registry.
Well yeah, but at the same time if we don't do it, then how is registration or how is payments going to come up with an API that deals with it, right,
and payment can payments group them every condition. Merchant registry required by the way merchant registry should have these details for me to confirm
already define those,
it's already defining the API. Okay,
well that's fine, so if you've got that defined and you've got a specific API already, then you can just put it as a precondition that you must have a registration component, you know, and, you know, I think that's okay as long as it's clear what it does functionally and what the API's are, then you can just leave that in the, in your building block. Okay, yeah. Yeah, and then we don't really need to, you know it's just like I guess a reference implementation, you know, the risk is if we don't specifically say, this uses a registration building block, then somebody might develop, you know, whoever's doing the reference implementation might just roll their own, which is okay, but you know you might want to say that, you know we strong opportunity,
opportunity to use registration building block registries building block for for this purpose, this purpose.
Yeah. Because then, with registration and registries you get both the database and you get like the ScreenFlow for like the back office to deal with it, right, which is kind of what you guys want you don't want to, you don't want to say payments is handling Screenflow and back office logic, right, you're just, yeah, right. So, I'm what I would do is exactly as you've done, call out the API's call out the functional requirements and say that this should be done using a gov stack registration and registry components or building blocks.
Okay, we will include this in the
API, define an API as to how we will check it.
Yeah. Yeah. Right. Right, so, uh, so I'm just gonna say, so payments will include a precondition,
you know, requiring a voucher redemption. Partner component with API's, you know.
Okay, great. Awesome. So, okay, anybody have any other questions, comments, concerns or just payments have any other questions, comments, concerns that they want to raise.
No, not on my side.
Okay, cool. Great. All right, so, sorry we kind of skipped you for the standup but glad we caught up with that. Okay, so let's see, uh, so, um, you know, I guess, you know, information mediator, I mean this is sort of like the previous key decision right so Taylor you. Do you want to just talk about this publish subscribe thing and see if we can nail it down I mean, that might be helpful. Is that something you wanted, you said you wanted to do or shall we move on to the checklist. Okay,
yeah, it is. So, there's a, there's a post in discourse that I was hoping people would take a peek at. And basically what we've,
we've
been getting a lot of pushback against PubSub, basically, folks saying that there's, there's no situation where ministry in using gov stack would actually want to publish something for, you know, other registered authorized gov stock subscribers to subscribe to. Yep, I don't know if that's valid pushback, the people from Estonia say no you shouldn't use Pub Sub, we do it. Yeah, Estonia, but lots of other people are basically saying like no like this should, this should not. It should not be part of Gov stack, because nobody will ever use it. And I have a hard time commenting on whether or not that's, that's valid perspective.
One comment on this Taylor. I was sitting part of your group, and I am seeing this viewpoint that I think it has more to do with the name and the modality formal modality of what pops up means, right. So, by definition, we are assuming box of means that the center of the event, need not actually know who are all sampling this event and what they will do with it. Yeah, it's completely out of their control, and the guys who have subscribed for the event, have all control of what they want to do with
it. Well, and also, also when you're subscribing though, you also don't know who, what material services you're subscribing from you just subscribe to an event that's pure Pub Sub right.
Yep. Yeah. But yeah, so if the event said child's born, and it doesn't say which child was born, where it was born when it was born. Right well. Therefore, I think if we are ready to give up the nomenclature called Bob sermon, you know prisoner with a new name. Yeah, that functionality, I think is very much necessary, in terms of allowing very public broadcast kind of events where you want for many many many organizations to know and your own care. And also, plus other things which are controlled that. At the center, knows that among the subscribers only these three guys or five guys should know this. So, we therefore need something which, for black of, I don't know what else you can call it apart from pops up, but X Y, Zed, if X Y, Zed is what we are going to call it. Let that have both of these functionalities because I think along those lines. Some work has been done in the building block group, a lot of drilling has happened and Functionality wise that is ready to use title has to change.
Right, yeah, so, so but on, on, on this the I think the second. So this is sort of this context to in my post is what Ramkumar is discussing now context, one is the hat it no matter what. This is just a separate application or applications that follow the exact same rules as every other application, which provides services on GOV stack. And those rules are that they must be registered under a member, they must sit behind a security server. They must have an application and valid open API specs for all the services they provide. So, given, given that bit and given sort of the very live very hot debate on around like what is the functionality that we want this puffs Pub Sub or gov Pub Sub to do. And then finally, given the fact that at the time of writing. There aren't any use cases that use Pub Sub, the somewhat provocative motion was cool, should we just cut everything from Pub Sub out of the infamous document, paste it into a new document called Pub Sub building block, and then leave it there. So as soon as we have a use case that actually wants Pub Sub, we can pick up all that nice work and develop a Pub Sub building block, and that's the proposal in it in full I'm not ready to stand behind sort of one way or another, but I do want to lay it out for everybody so they can weigh in on it.
The way I would say a tailor is if you, if we look at the services, they will find my colleague to, like we have indicated in the definition template to two sub functions that we put one was for services, exchange discovery and exchange, and the other one was actually the event gateway if you call it as Pub Sub as event gateway for example. And the way I would look at it is, are they orthogonal, is there anything that a depends on B or B depends on a that makes them really sit in one box. If not, it's okay we can we can call it two building blocks, it doesn't matter. But you will because it in time to come, if there are use cases to use the second, the event gateway later, it can be defined and used like any other building block, because that also actually hangs from the information mediator right. It is another one that will be like for example registration block and payments blog this block will also be connected to information mediator anybody who wants to publish an event will go to that block and dump an event, and it will manage publishing it to various people with guys who are subscribed. So in that sense, It is, it is not actually doing any thing overlapping and correct me if I'm wrong, is it doing anything, overlapping the, for example, what an extra does
it sorry pops up.
Yeah,
no, either.
So first of all, first of all, I mean I just want to point out that, you know we can't use traditional Pub Sub we have to use a point to point method to keep security benefits of information mediator. So doing that means that subscriptions for each publisher that could send an event, right. So in traditional Pub Sub the subscriber doesn't need to know the list of Senators but you know in our system, each subscriber would need to manually go and register at each host in order to not break the information mutator security model
wouldn't know. I mean, that also that is that say, that's a business requirement that's not a technical requirement because Pub Sub is a an application that provides services and sits on the Iam just like anything else, and, per the im security model. If registration wants to publish to Pub Sub, then it needs to gain authorization to use that publish service on Pub Sub. And likewise, if, if I don't know, something else if making another payments if payments wants to subscribe to events from Pub Sub then Pub Sub that application was just a regular old application like any other one in gov stack it needs authorization to make POST requests to payments. So you still have your, sort of, you still have your point to point security model, it's just that you're putting a lot of trust in this global Pub Sub application
yeah so we can't do that. We're not going to do that. I don't think that I think that if you do that then you're just opening up a gigantic security hole so
Max Max. Max before jumping onto it. We can't do what we can't,
we can't have a separate building block that is traditional Pub Sub. That would just, you know, that doesn't really work. I mean what you really want. So I think we should step back and think about use cases. First of all, I mean I think that's a really valid point like there is no, you know, yeah, there's no use. So, either we write a use case, or we defer this, right, like that's kind of like point one.
I'm with you, I'm with you. And like I don't I don't Yeah I don't see why we should spend so much time sort of trying to redefine this really standard technology to make it fit our specific case, if we don't have a single specific case. Yeah, so I
mean, you know. Yeah, exactly. So, um,
so, so in that in that in that case, are we saying that there is no event propagation happening to to consumers in the current user journeys and use cases where we don't even we don't like there's
lots of, there's lots of event propagation happening like when, if, if somebody, if somebody is born, and wants to register that new baby, with the National Insurance Scheme. The application that intakes the baby sends a post request to the application due to a service on the insurance application which, you know, allows people to register new insurance participants.
Right, yes. So let's, let's, I'm just going to pull up this diagram here, just because it might be useful to just look at the registration for postpartum infant care which is like, you know, you can imagine, right so there's lots of data flow here, but none of it is based on publish and subscribe, it's all, you know synchronous communications and callbacks.
No. That is because this is right in the loop right there. This is all part of online transactions. Yeah, right, triggering any events that are asynchronous and offline.
Right, so, you know, if we were to add a use case, you could in theory, send an event, right, that says, oh there is a new child. Right, yeah, the new child has been, because this is basically registering the mom and the new, the new baby, right. So yeah,
from the, from the Civil Registry, where we registered the child and or the mother. Then for each registration. The system could send out message that new child has been born or registered or whatnot.
Yeah, so I mean just hype, hypothetically, you know you could do that. So, you know, I guess the real question is, if we if we were to do that let's say Civil Registry. When this registration occurs right here. This registration complete. In the Render Civil Registry. This could also publish an event right here. So, hypothetically, right. So, I guess, you know, what's the real value of that. I guess it's kind of the question right, that's one of the questions. I think it's worth talking about it, you know, in the context of a use case. So what would be the real value of doing this right. So to me, other, you know that that's the other side of it right so we publish an event here so what, who's listening for it. Right. Um, you know, you could have another registry which is like a population registry, right, and it just listens for these events and, you know, knows to update the counter and goes, goes and counts the citizens and as okay. Now there's one more, right, and then it can publish an event that says, Oh, the new population count is, You know 100,001 Because there's new baby. Right, so all these things are possible. Um, you know, the question is, is it a requirement for substack like right now to do this like, it's something that we really wanted to put in there, Like I really wanted. Um, you know, because then you can build all sorts of loosely coupled applications but, you know, to be clear, that would require anybody who wants to find out about this birth to connect to this specific Civil Registry, right through the information mediator, they would have to subscribe to this instance of this building block, the Civil Registry. And that's because the information mediator has to determine whether or not you're allowed to make that call to do this subscription but yeah, I think it's I think it's Max, I think it's really powerful to be able to so one more point that I wanted me. Yeah, there's like this idea of having another building block which is a Pub Sub building block which you're floating. I think it's really powerful to be able to if we're going to do this to be able to subscribe on the building block itself, right, because it's sort of a forcing function that says, Okay, this is a first class piece of functionality that's built into substack. So the building blocks should consider publishing events and it's like, whereas if it's something out here to the side, then that's not going to happen. So that's why we've been pushing this idea so hard, so sorry go ahead.
I'm thinking it might be. So, given that the security model for the information mediator is based fairly heavily on X road. And given that the x road is stonier implementation. Apparently, per per our conversation yesterday, apparently, Estonia X road, and the whole gov tech architecture and Estonia makes extensive use of Pub Sub it, maybe it would be worth getting some of the sort of Estonia representatives to provide at least one of their currently used at scale on X road Pub Sub use cases. And then we can sort of evaluate that use case and say okay this is being used at scale by real government today, same security model as our information mediation layer, like what's their use for Pub Sub, and then we can sort of evaluate that use case and say no that's dumb, we don't want to bring that in, or yeah, let's, let's do it because it's real and being used at scale, but that would be really cool to sort of hear them explain how they use Pub Sub and how they do so without breaking our, our I am security model, right, so it's easier today.
So, you know, I can give you an example and this is sort of, So one of the people in the messaging group, and I can't you know they're coming up to speed fast so hopefully we can merge them in and they could join in the coming, you know, week or two. And these groups, group across group meetings, but you know one of the things that they've done is this chat bot that basically a citizen can go there and they can ask questions of the Chatbot. And the Chatbot essentially will, you know, uses, you know, natural language processing, and some AI to determine which, you know, and then it, then it will actually go and ask all the different ministries. Here's the question that's being asked, Who has the best answer. Right. And then all the ministries respond and say like, Oh, I've got an answer that is like 85% I've got one that's 90%. And then it presents those back to the user and says you know well, you know, this sounds like an issue with passport so you should talk to border control. And here's their contact information. So, that is a very specific concrete use case it's called crop AI, that's in the Estonian government that's being used now. And it would be difficult to do something like that without publish and subscribe.
No but, but, is that not a subset of the overall scheme that you're talking Pub Sub is then one subset where you publish and you don't get worried about lessons. The publisher doesn't care.
So they're not caring who's listening and not caring who's subscribing doesn't work for us because it breaks the security model. Yeah. So
that was one point, Max, I completely agree on that. The other point I'm trying to see is, I picked up a different signal from what Taylor is saying and correct me if I'm wrong, Taylor. The thing is that the list of subscribers. The list of publishers have they is the Pub Sub. Let's call it pops up for now whatever reason it is the functionality of Pub Sub plus directed communication. Right, so the list of subscribers and list of publishers is maintained by the Pub Sub itself, right, it's not maintained by the service exchange component is it that,
that's right. Yeah, she is an
edge component, Bob serve is like one more server one more service provider. We have one more building created easily going to do this job, so it is going to maintain its own list of publishers and subscribers and so on but only thing is, anybody who wants to talk to this Pub Sub die has to come through the information media, like any other building block.
Yep, yep. So,
if that is the case then can we call this, this pops up plus plus model as a building block on its own right. As everybody who wants to use that model can go through the information mediator to talk to it.
Yeah, that's one thing that I think that's yeah that's that's that's very So Taylor, do you want to talk to talk to
strangers onto it, you can enable it for directed communication and unsolved it's I mean you can just do a broadcast through a multicast through it.
So yeah and so now, now we're talking. So just to be clear, now we're talking about adding an imaginary Pub Sub building block over here to the right,
yes to that. Anybody here, based on their scenarios will just go and publish an event title barn or some security breach or whatever it is you can just go and publish it to the broadcast. Now the sender, the sender takes care of telling. I don't care. It can broadcast it, or the sender says, I need this message to go to ABCDE only.
Yeah, I mean that's a problem right. Yeah, and that information about who you can talk to really kind of belongs over here like in the Civil Registry not in some other building block where if you miss configure it, you got a giant security hole.
It's, it's the attorneys follows the distributed architecture, so that you should not have all the eggs in the same basket, but it seems that we're currently talking about having a bongos, one single point where the whole government is sending some information so not sure if it's.
Yeah and I think that's a really bad idea. So I think that's another, you know, another reason to actually have it be somehow included conceptually in part of each of these building blocks, right, as opposed to some separate component. So because I
mean, let's say that if, let's say that I'm registries, digital registries building block I have the register of mother and child. So, if, if anybody is interested in in listening, whether there is a new registration done or not, then I would have to have an API would would input somebody saying that to register this IT system, or this URL to to Mother Child program and notify me whenever something happens in there, new registry, so the registry, the registry is building blog will then, when, when it gets a new registration, it looks from the Sub Pop, that there is a somebody interested in this event. So it sends out to this, another, another service that here. Here you go. But if this other service is down, then it will keep on trying to guess right.
Not only that the consumer of this particular event, then has to each consumer has to know where all their to look for, which building block that would tie up for which flags and go and actually contact all of them and register with all of them.
Yeah, exactly. Which, which I think, I think, is, that's exactly right Ramkumar and I think that makes sense because it's just like, it has to know which building block it's going to call an API on. Right. So, I mean, I still think we have this like question though, of like how, you know, I personally think it's essential functionality but I'm not sure that I can make that argument on my own. So, you know another thing I'm hearing from you Taylor is that, you know this is kind of holding up the publication of the information mediator. Right. So, what we could do, you know, too, so that's which is kind of a separate problem right. Like, is it part of information mediator or a separate building block, I mean I'm convinced after this conversation more than ever, that it should be part of information mediator, actually, because then it's distributed, you know, but that's just my opinion. But I think, I think we should maybe just say, this will be, you know, something that is part of information mediator, 2.0, or something. Right.
Max, I don't really understand what to add to the information mediator, meaning that it's each building block that needs to have standardized API's, which are exactly the same in each, each place, so information mediator is just a channel that it's securely exchanged information but,
yeah. So I, you know, maybe it's maybe it's not you know so so technically speaking, there's a security server that you go through to talk between these building blocks like each of these interactions between the arrows goes through on those building blocks right. So, you know, technically that's enough to build publish and subscribe. However,
if I really feel like the put it on the table so let's think through this. I really feel this kind of event synchronization should be put in the workflow building block. Because all this, you know, things that are navigated and coordinated are all probably landing in the workflow building blocks, based on the events. So everybody comes and publishes their events. And the workflow building block and make sense out of it and trigger the right dice,
well yeah but you're conflating two different things right there's a workflow building block right which might be listening for an event. But in order to listen to an event, it has to, this has to be able to publish events.
So you can publish to the, I am just saying this pops up can sit inside the workflow building block,
I don't think it can. I disagree. But, you know, I mean this is kind of like it's a longer discussion. You know, you know, I have like really strong opinions about it. I think we should put it to rest but, you know, I think we should you know come up with a really compelling use case, first of all, and use that to drive further discussion, and second of all, you know, and talk to Estonia about it. And, but second of all, I really think that you know if your concern is that it's holding you up from publishing the information media or spec Taylor, um, then we should maybe just defer it to a subsequent revision. Um, or, you know, or just push through and say like, Okay, well it's just going to take longer, and like really aggressively nail this down like in the next week or so.
Well, I mean I don't think it would be responsible to like to include it in this spec unless we have a use case for it.
Exactly. So, you know, let's take a week to, you know, identify a really compelling use case and if we can't identify a really compelling use case then we just defer it, you know, let's say we're gonna, we're gonna move this out, you know into version 2.0 or, you know, into the future
version 2.0 and leave it there. Well publication can happen
on this question, first question.
Yeah. Yeah, okay. Yeah, on the, on the point about workflow, and the relationship to to Pub Sub and to the aim. I just want to take the chance to sort of stress again that workflow is a building block. And that means that any application built using, say, the Civil Registry building block or using, say the payments building block any application that makes use of one of those building blocks specifications to create an instance, or an implementation, it, it will likely have its own workflow engine, and that workflow engine should adhere to the workflow BB specification. So there there may also, you know, some, some developer that sits under some ministry may very well build a workflow engine that is granted authorization to interact with a bunch of different building blocks, but there's nothing special that workflow from that perspective, either. So like, Where were these different instances of workflow engine set, which all adhere to the workflow BB spec is sort of just up to the client and what they want to implement. There'll be, you know, two dozen or three dozen different workflow engines in a gov stack instance and some of them may cut across different building blocks and different instances for those building blocks and some of them may not.
Yeah.
Okay, that still lines up with everybody's understanding of
workflow. Yep. Sounds good.
Yeah, rather than like the global centralized workflow that is keys to access every system in DevStack
No, it's got to be distributed, like, yeah,
yeah, and it's not, I would like to add that workflow, building block is not only a sub block of some other building block but it's, it's also can also be used to stitch flow between building blocks,
well that's what it's doing here, right. Yeah, conceptually, or it could be, could be doing more of that, but. Okay, so, um, so, you know. So what do you what would you like to see have happened, like Taylor like what's what's your, what would your hope be for this publishing subscribe thing.
I, I think that publish subscribe is a good idea. I think that the pushback about governments never being willing to use Pub Sub is wrong, I think that comes from a misunderstanding of Pub Sub and and and maybe around Kumaras point just like an icky feeling that people get when they hear the word publish because it sounds like public. And I would like the team from Estonia, to give us a use case that is currently implemented on X road with Pub Sub at scale for the Estonian people. Yeah. And then I would like to show that use case to the rest of the people that don't stack and say, hey guys I think we can use Pub Sub in gov stack. And yeah, I, and then if we have a use case and people accept it, from the World Bank accepts it or whoever like signs off on use cases, then, then I think we should, we should finish up the Pub Sub stack and we should rely fairly heavily on how it's done. He has implemented Pub Sub as like the template for it.
Okay, great.
I don't think we should do any more work on Pub Sub Do we have a use case perfectly. I think we should just put a pin in it and cutting it from the document and pasting it in another doc that's fine, but if it means just like, you know, putting it in blue rather than black in the im doc I, sort of, I don't mind either way on that.
Okay, so, so let's all reach out to folks who we know like I'll talk to the crowd, I go, guys. I can also talk to Ireland. The head of digital they're like Tony, you probably, I mean he's super cool, so he might have some suggestions. Yeah, so please reach out, you know. So, really, really use cases for Pub Sub or citizens,
we haven't, we haven't freestyle as well and yeah, we're very familiar with those topics.
Okay, so use cases.
Yeah, okay, Okay. To Christo and Krut,
folks.
And so encourage everyone to okay so let's do that. So we'll pause work on pumps up until we have a use case.
Great. All right, excellent. So anybody have anything else you want to talk about this pumps up I think this is like really fruitful discussion. We got to get it nailed down.
Yeah, I'm happy there. And I'm. For the record, pro pubs, and I think it's a good decision in architecture really. So hopefully we can get a use case written down and we can get other people on board with it.
Yeah, I mean I'll make it happen. Because it's like, it's like this is like, you know, I think it's really important to have it. But yeah, it has to be properly justified.
Yeah, totally. And we can do we can borrow from whatever Estonia is doing to like glitch to Estonia not only give us the use case, but show us how they implement it and that can be the basis for our Pub Sub spec. Yep,
exactly. Perfect. Okay, So I guess we can put this issue to rest for now. Sounds like we lost some folks. Okay, no worries, so I guess maybe, you know, in the few in the remaining time we have a rump bar, Do you want to go through this checklist.
Yeah, so I just wanted to check is this. There is no latest update date on this so we wouldn't know. Should I take this as ease, and take a snapshot and put together the overall scheme or for the team want to update this.
So you can see why you can look at the version history and you can see like people have been updating it, like, you know, you can see who did it when but it's like you know, it kind of tells you what you need to know. I mean what I would do is just say like hey guys, we're gonna snapshot this as it is unless you update it and just give people a deadline to update it. Maybe,
yeah I think so, but yeah so I'll let us say we will, I'll take a snapshot. Monday.
Okay. Okay,
people finished that update by the weekend if they have.
Okay. The checklist.
By
Monday of next week when it will be for the monthly meeting, right there.
Okay, cool.
I laid it a day before. Yeah,
perfect. Okay, perfect. So, um, oh, one more thing that I wanted to talk about is that we're doing this publishing of these PDF files, right. So we got the security building block and architecture blueprint now. You know just rough versions or rough drafts. I wanted to encourage anybody if you feel like you, you know you want to publish a draft any version, you know, just an early draft as a PDF to, you know let me know. And we can like formally publish a PDF for you. Um, If anybody would like to do that. And the reason we're doing this again is so that you know the reason that in particular this architecture blueprint non functional requirements is published there is so that you guys can refer to this version, and say 1.0 point one. And, you know, A and Section 3.1 dot one right like that. Right, so that you can do that and know that it's static right this is not going to change out from under you, because this is published at a specific point in time. Okay, so reminder about that, you know, to please refer to anything or security related or blueprint related using these URLs, like these PDF files and bisection number. Okay, great.
X there was one point we had to discuss was about the open API. Jason specking right, just want to update because I wrote a note to you and timbered, and I think Taylor, but just to let all the groups now that his name is Irish right yeah Irish. Yeah, has volunteered to work with the teams, but nice request to a bit of familiarization with this whole Jace and yeah the PSP.
So I talked to us earlier today and just gave him a onboarding of an open API and what we need. And, you know, also it seemed like we're probably want to try to publish the information mediator spec, like next is probably the closest, especially if we can remove this or defer this Pub Sub stuff, we could do, we could get a version of that out, right. Yes, you know, provided we had the open API specs and those are pretty close so I asked him to focus on that one first. And the elbow open API for that just rather than any building block but, you know, groups, you should know that we do have this resource, he's like this awesome technical guy from ICU, who can help you translate stuff and write out your, your open API specs.
Yeah, but he will not, he will need your inputs, your respective group is not a domain expert in any of your domains. So, require inputs and he can, he can put it in that format. That's the idea.
Right, so your belly, provided that your building block specification has like formal model declarations, you know, and API specs, written in some way, then it'll work for that, then he can help you get it translated into, you know, formal open API specification. Yeah. Okay, cool. So I'm gonna just add a note here. Yeah. Just a note that a huge will be,
we'll be helping with open API specifications. Starting with information in mediator,
open API specification from it.
Yeah.
Yep. Okay. Okay, great.
All right. So anybody have anything else. It's been kind of a long meeting. A good one long one but a good one. I feel like we didn't get through, we didn't get to talk about, you know, Id stuff that much.
Great. Well, unless anybody has anything else. Anybody have any issues with this course. Right.
Yeah, I wanted to talk about this course maybe you can know some technical topics a little bit. I don't really understand the logic there, try to understand what the documents go so maybe you can just open the discourse.
Yeah. Okay.
First of all, I didn't see all the building blocks here so, are there any any logic theories, there's only a registration but not no digital registries.
No. Okay, so we need to add a registry building block section to go there. Okay,
digital, digital registries
yeah okay so
for that. And second of all, I didn't quite understand that you have this meeting minutes kind of section there but no, it seems that I don't have the access right to add those blocks there myself.
Right so, you know so architecture, you're saying architecture has this meeting minutes section. Yeah, and the other building blocks don't. That's actually a limitation of this course, you can't have one that's another level deep, it's kind of lame, but, um, so you can't actually the building block in here, you're not going to be able to have a separate topic for meeting notes. So,
we raise them up upwards, just like an architecture or is it the by, by design, that building blocks should be one section lower as as architecture.
You know, I don't know
the title already says building blocks. So,
yeah, exactly. So, um, you mean so like if these were just parallel with architecture it was solved that problem.
Yeah, yeah,
yeah, just to understand that not any way criticize
so you know I don't I don't know, you know, I didn't set this up. Um, so, I don't know what the thinking was, but, um, this is just kind of where we ended up from the you know, Steve from dial set all of this up for us. So, yeah, I mean, you know, the idea was it just I guess have some hierarchical separation here, but right because there's use cases cite feedback like there might be other top level topics, was the thinking, I think. So, um, you know. So strictly speaking, you don't really need like a separate specific topic for your meeting minutes, you can just include like, use a subject line that's meeting minutes with the date and then that'll automatically group all your replies, if you just see see like your information mediator at discourse, Gov set, global, and then your subject line has like meeting minutes, then, then that'll kind of group all of the discussion. It doesn't keep all the meeting minutes under one topic though, right. So, in order for that to work, we would have to reorder restructure this and move these up into the top level hierarchy, right like so, just so you're clear architecture group has this separate section where we can put all the meeting minutes, and you guys won't be able to do that unless we rearrange stuff. Does that answer your question anymore.