wait I actually I made sure that I joined the session to get some updates on that. Okay. I don't know I just third hand information but not from my direct colleagues who were there yet. So sorry for not turning on my camera somehow, since I updated we lost. I don't even have access to the right management to. I don't know maybe just blocked.
Oh, it's implementing a team's or bust policy.
Yeah, exactly. Yeah.
Maybe they noticed I have a zoom installation is inclined on my computer
to be to be, um, well good so I mean I guess while we're waiting for folks to join. I mean, I could give you an update, I mean we had a great session it was mostly it started out with this conversation around, um, how procurements gonna happen, which is pretty interesting. Um, and it seemed like it was going to take a long time, and then we're going to try to do everything all at once. So then we sort of step back and try to reframe the discussion, and think about, you know how we could get something functional sooner, and how we can break things up into, you know basically use test driven development and take these open API specs as they're developed and then turn them into stubs, Basically, and build demos against that. So that was an interesting discussion. Pretty fun, and then the other big highlight for me was try to attack this Estonian like punk rock techno. I mean they're folk, it was like folk music,
old folk songs in and sort of a Technicolor dance rock.
Yeah, it was awesome. So that was a great surprise, and then the other thing is we just kind of let all of the groups just kind of give feedback, and as we're, I was expecting this to take just the morning but when I'm taking, like most of the day. So, just everybody kind of talking about what went well, what hasn't gone well, um, you know, asking questions, so that was really productive, I think, um, there's good to do that face to face, you know,
I was dependent dependence, like how many people are joining from all over,
they're supposed to be 30 but there are about 40 people there. Um, and then the yeah it was it was it was good I mean it was a it was cozy. And then there were some side discussions around like governance that, you know, I wasn't really a part of I just kind of heard about after the fact. So I think there's like a parallel track on governance which is just, you know, how do we adjust the governance of this project so when one of the good things that came out of there that I'm pretty excited about is the notion of having a product team, having a group that's specifically dedicated to gathering requirements and defining use cases and things like that, which I think would be a good direction because, you know, like there's, it's always good to like they would be responsible for, you know, talking to the government of Djibouti or whatever, wherever we're going to deploy are in Ukraine and figure out, you know what are the, you know, I know guys that is doing some of this but kind of formalizing that. And, you know, there's also talk of this tech governance group which, you know, I'm a little less clear on but I mean it seems like a good idea. Um, which would be kind of similar, I think, but just more along the lines of, you know, having a neutral third party group that vets those specs and whatnot. So a lot of stuff came out of it, um, you know, It was also like the talent digital Summit, had really high production values. Is it was surprisingly good and fancy and there were lots of really important people there. So that was pretty impressive anyway and it just kind of made me realize like what a big deal job spec is to a lot of people. So we're definitely kind of in the spotlight now. So that's exciting. Um, you know,
whether a little squeaks from attending.
Yeah, David was there Sarah was there, uh, who else Christian. Yeah, yeah so that was super fun getting to hang out and meet them, good people, really good people. So, next time you get to come. Hey Arnold, welcome. Hi, how are you. Good. Good. Hello Hey Alex, how you doing, I'm cool. I'm so yeah I was just giving eBay an update about the, the summit, and all that. So that was that was super fun. Um, so just give folks a few more minutes to join, oh the other thing that we talked through is, we finally went through these, these flows that we've been kind of working on and talk that talk about authentication and authorization and kind of vetted those with the ad group for the first time, which was super great paying more. Um, so I think. I think we'll get some, some, some enhanced use cases and flow diagrams I'm hoping in the next week or two from the ad group. So that's, that's super exciting to see that coming together as well. All right, I'm gonna turn off my camera, because I'm not sure if it's killing everyone's bandwidth. Yeah. Okay, I'll do this thing. Yeah, so, um, yeah, so it was a productive time good time. Um, yeah. And so I, you know, I'm hoping that we'll be taking a much more nimble kind of agile approach to the actual development and doing kind of test driven development doing a lot of prototyping. So a lot of those discussions are ongoing, but at least you know people seem to get on board with that idea, at least in the technical side. And then, you know, on the policy side. You know I think that there's their ongoing discussions around that the governance so just getting everyone on the same page. So, um, oh, I guess like To that end, you know, this might be a little bit premature but I'll go ahead and, you know, if nothing else, I'll share my screen and share this slide deck that I sent honey, um, which just kind of gives a summary of what we're hoping to, you know, the changes we're hoping to make Can everyone see that. Yep. So yeah, That's a whole like mouthful of like buzzwords, but the whole idea is to, you know, start prototyping with what we have we can use x road until inflammation mediators ready, we can use registration, as it is with MTA and you know all the, all the awesome work that Frank and Mr of Don and others to prototype the screen flows, it's already connecting through x road. We can build, you know, visually compelling prototypes using this, and demonstrate them, while the functionality is being evolved across the entire system. We can demonstrate building block functionality early during the specification process even before development started just by taking the open API specs and stubbing them out, and then also the other thing that came up is we want to start development of a UI building block to help ensure clean separation of UI from, you know underlying API's across building blocks, including registration, but also to provide just a generalized container app and solve this problem of how you provide the list of services that a government provides, and just have styleable, you know container for that. So that's underway just, you know, early ideas, um, then, so we'll be doing test driven development using placeholder functions so
as new building block open API specs are made available we create stub placeholder functions using the swagger you know something like swagger kojin, then they would return static data for example, Id foundation ID could return the same result for different inputs to start, even in advance of the development of the ID building block. Then we create automated tests to validate the output of placeholder functions and provide clear integration points for developers. So we could for example add a test that only passes when different inputs, result in different outputs from foundational ID off, right, and then that gives a building block developer. The ability to fill in the blanks and incrementally replace these placeholders stub functions with real functionality and get quick feedback. The test would be continually refined as we evolve functionality in each building block, and then the test would allow automated validation of compliance and and automated building block certification. Stop me if you have any questions on this stuff, but, um, so this is what we're trying to pitch, and then, this enables Hey babes. Yeah.
Can I just sort of say it backward expand a little bit on the like swagger specs and code gen stuff. Yeah, make sure we're aligned and I'm quite quite keen on seeing that move forward. So I think the the idea in my mind is that, you know, our open API specifications. If we think of Gov stack as this like set of open API specs that went in here to facilitate this really nice sort of scalable federated architecture, right they like make digital transformation for governments easier by ensuring that all the building blocks, they're using can actually talk to one another. Like many many many different products might fulfill these like minimum or barebone requirements to play the role of, say, an information mediation layer or to play the role of a workflow engine or play the role of a registration application. And so the, the open API specs aren't the full open API specs of those different products, rather they are like the minimum stuff. You have to adhere to, to participate in guff stack. Is that right, is that, is that still sort of the the idea there, or am I understanding that right.
Yeah I think so, um, you know, but any functionality that's needed to connect building blocks should be in the open API spec, but it's not going to be everything, right, because there's, you know, for example, if you think about ID, or, you know, even the security Iam internet you know identity access management block those are gonna have their own UI and their own sets of API's and those, so it's going to be a subset of the total set of API's in the building block for sure. That makes it easier and quicker to adapt a new kind of, if you want to try a new ID in our system or a new identity and access management just drop it out into replace it. Right. And so this gives you know so this is like kind of what we giving developers a template where they could just fill in the stubs or, you know, adapt them to their specific tool, and then it becomes substack compliant.
Yeah, yeah, and that that was another thing that I think came out of the conversations last week was that, you know, say we, we go live with these open API specs for gov stack v1 At the end of the year. We could publish those. And then, you know, maybe there's a lot of overlap between the information Viator spec and extract, because we're using x rayed is like this sort of best in class example of an inflammation mediator, but as soon as that spec is published, then a bunch of other applications could write a little layer on top of their API and they could write a little adapter that would make their application effectively GenStat compliant. Right.
Yep. So that's the idea. Yeah, and then the other cool thing about this is it enables micro procurements, because, you know, we saw this, you know the the plan for procurements was that you basically try to get everything developed at once. Right. And if you try to do that then the cost is going to be really high, and then there are all these procurement laws in the EU that come into play. So you basically are limited to only huge players like SAP and IBM, and you know that, okay, I guess, but if we can enable the ability to do micro procurements, then we can have, you know, hundreds of developers collaborating and getting paid, instead of just like a few large players. And this came out of some conversations with the digital, digital public good alliance. They had some success doing this so, anyway, the idea is like with active management mentoring we can build capacity and ownership in country by offering micro procurements to fill in missing functionalities like a PG PhD student in Djibouti could build a small incremental piece of functionality right. Um, and, you know, potentially get paid. So, and that reduces risk because some procurements can fail as part of the learning process, anyone can pick up the testing framework to add features improved functionality, even as a volunteer, all developments done in the open, increasing visibility and engagement. And the smaller procurements provide more flexibility and allowing more parties to be involved with the development, which is key for capacity building. Because I mean, it's much better if we can have people in the places that are going to be using DevStack during the development, because we're closer to the ground, than having us just say, Oh, we think this is really good, good idea and, you know, take it. And then it. This allows competitive tandem development like X PRIZE so you can have a, you know, potentially, three people competing to make the next baseline functionality of X road and have these phased kind of development competitions, which is something digital public goods Alliance has had done to good effect. So that's, these are all kind of ongoing discussions I mean this is, I'm not saying this is the way it's gonna go but I think it's a really exciting direction. Any questions about this,
the example from Djibouti, just as an indication that Djibouti is really starting off with this now or,
no, no, it's just, I mean they're in the Horn of Africa, they are one of the countries that we're talking to and, you know in evaluating, but the idea is if we can get these countries, there are about nine countries. You know where we're, you know, looking at actually deploying gov stack now. And so the idea is, you know, that's just an example, right. So, any country, I mean I think the idea is that it would be amazing if we can partner with universities and actually have engagement from people living there. In terms of developing AppStack and adapting it for their environment. Yeah, but, you know, yeah, okay, yeah. So, the information meter is closest to maturity, so we should focus on that first. For procurements, and then rather than one large procurement we could do three smaller phase procurements and a competition with these deliverables to evolve the best solution. Right. Again, pushing this idea of micro procurements. So, you know, I kind of suggesting we stick with the existing use cases of postpartum infant care and unconditional Social Cash Transfer that we worked so hard to develop, to date, and then, um, you know, we just on boarded several new teams right so we have workflow and consent management and messaging groups now starting up. So the idea is to kind of revisit those use cases and refine them with those groups, and in some cases we've identified messaging and, you know workflow functionality already. So just kind of trying to stick with that. Yeah. So
you said three. Three procurements in media, current here is this use case inside Well, it is the same thing for what what is three smaller phrase procurements,
oh so like the idea is about the use cases or not. No, I mean, the idea is like the information mediator spec is probably closest to maturity. So, and it's also the foundation that we need to connect all the building blocks together so we can start out using x road, but in the meantime, we could, you know, basically fund development of information mediator, which is like x road but, you know, really might not be X road in the end, right, at a minimum, it's gonna be so the idea is like potentially we could have three different people compete to do development of the information mediator, building block, right. And then, you know, choose the best two and then continue to pay them and then choose the best one, or something like that.
And there's, you're saying for the for the demo effectively
do. One of them is it fraud or how you see,
yeah I mean it could be absolutely right. It's just an idea, right, it's kind of like a far out.
You don't have any three particular procurements in mind you just bring this as example,
yeah this is just an example. But, you know, we could just essentially have three different people develop it like one of them could be nice for example like the developers expert could could try it, they could take on development of, you know, and compete with someone else like maybe someone else wants to build information mediator, on top of the matrix protocol, right. So maybe some firm wants to do that so we could, we could open it up, basically to three different developers, and then just see which one ends up being the best, right.
And and and which one ends up being the best for this prototype, right, because like the thing that's produced by that is not sort of the information mediator building block. As far as I understand it's just like an implementation of the information, mediator spec for this particular prototype, but then when we, when we move from, you know the prototype that we're working on with Djibouti to say the Kenya implementation. They may use that exact same thing or they may again, Like, modify some other system to adhere to the information mediator spec right so it's not, it's not like a finalized product after this procurement it's still it's still a spec, but it's like an example of an implementation that adheres to the spec.
Right, so the idea is, we were putting these specs out for reference implementations right. So, how cool would it be if we could have three of them being developed at once and competing instead of just one reference implementation right
yeah exactly is the especially especially if they're small, yeah small approach intervention is not lots and lots of money. Right,
exactly. So anyway,
So this small, you don't mean my. Oh,
no I don't think a micro would work for this. Yeah, I don't think it would work for this right and it's, it, you know, it really.
Oh little.
Yeah no I mean 8000 euros is not going to get you an inflammation mediator, right, so probably more like a quarter of a million euros or something. Right, yeah, okay, okay, is what I'm thinking, but I don't know, I'm not the money guy I'm just like trying to make this process move closer to, you know, move faster. But this is not like this is just my proposal right like I don't know if anyone's gonna go for it either, so I
don't expect that honey is happy about that, in, in this case he pays for the same approximately the same thing three times.
Yeah, yeah, but you get three different versions, and you can sort of, you don't pay for the same thing three times, right, you would divide it up into like three phases, and then see who gets the best functionality at each phase and it's sort of like competing, it's just an idea from digital public good alliance. Right, so they had great success building a app for teaching, Arabic and Syria, how to read Arabic. Using this approach, right, as opposed to just, you know, having one huge, gigantic procurement. So, you know these are kind of crazy ideas. I'm not saying this is going to happen, but I think it would be interesting if we could, you know, it's an interesting thing to talk about right.
Yeah, at least we'll discuss exactly, so I just
you know full transparency with everybody, this is just like, um, you know, food for thought. Um, but, you know, in a nutshell like this for me was the most exciting idea to come out of the, you know, work last week besides just, you know, connecting with everybody and meeting them face to face. So anyway, I guess, we probably got. This is probably as many people as we're gonna get today. So, let's see, I'm just gonna,
and sorry I'm and I'm actually only going to be able to stick around for the first hour, so I've got like 4040 minutes left.
Okay, cool. So let's get started then, I guess. So let me just make a copy of the last meeting minutes it's been a little while since we've met, so. Okay, so, um, first of all let's go around and do stand up I mean I guess I sort of did that. Um, so, uh, please. You know, I guess who wants to go first and just give an update about where your group is how things are going, etc.
I'd love to. Because I can give an update on a new group. Cool. So we've had, we've had two meetings on the workflow engine group. And we, we just met, on, on Wednesday we just met yesterday, where we're sort of at the stage right now as basically doing a sort of a market analysis, trying to pull in all of these existing workflow engine tools we use in conversation with the architecture group and or internally within the workflow group. We've decided that it is, you know, it is important that. So there's a lot of different specifications. There's a lot of sort of different stuff that will that will potentially live within workflow. But we want to make sure that at least whatever we're putting forward is the minimum requirement. We'll have both sort of business process modeling aspects and Business Process Model execution aspects. And I want to just quickly quickly share my screen, this won't take too long. But we had a really nice, really nice presentation, prepared by Khalid, one of the workflow engine. One of the workflow engine contributors. How do I share my screen,
next to the hand in the lower left.
Amazing. Thank you, Max
can see it. Oh, Yeah, yeah, you can see it. Yes.
Brilliant. So yeah, I mean, we're so we talked about sort of the approach that we're going to go through and how we're going to sort of identify, and this is still just in like sort of assessing the market right this is not an actually writing up the spec. And what was really useful was thinking about sort of the different things that might be provided by a workflow engine, and which of those things will will sort of be musts and will be exposed by the API for direct interaction with other building blocks, and that just for one example would be the execution engine, because we've already decided that, you know the, you know, identity building block must be able to like directly sort of make a request that the workflow building block starts, some business process, like start some sort of flow. But then there might be other things, like an ID, we write, we might want to make sure that whatever workflow engines we're proposing for graphs that have a really nice ID or have a dashboard, or provide real time tracking of processes, and these things might not be part of the open API spec, because they might not be interactable from the other building blocks, but they're still going to be part of our requirements template because we want to encourage people to propose workflow engines that have all of these different pieces. So this is sort of where we're at, but really excited to get underway there, and more, more to come soon.
Very exciting. Very exciting.
That's all from my side.
Okay, do you have anything for. So I think in general, what we're going to try to do is have a separate meeting for the new groups, you know, probably on a different day in a different time just because. Yeah, so I mean this is, this is great but I just, like, I'm not sure it's viable to have eight groups in one meeting, I don't know I mean,
yeah, sure.
Um, especially because the other groups are probably not familiar with our, you know process that we come up with. But, but this is great. So can you give us a information mediator update.
Yes, though we haven't met since the since the cross, since the cross team in person. So the update there are maybe sort of a status report rather than update status hasn't changed since since last time. We are, we're at the stage where we are. We don't have our Open API spec defined, and we, we have maybe now. I don't know, 70% or something of the of the schemas for the different sort of entities within the information mediator, defined. We're not finished with the schemas. We are, we are like pretty pretty happy with, sort of functional requirements that are laid out in the building block specification document. And in our, in our next in our next meeting and in our next steps, basically what we'll be doing is, is answering open questions that came back from the Architectural Review of the spec, making decisions and logging them, and then producing the open API specs and the schema and schema model definitions for the different like entities within condition mediator.
Okay, great, exciting stuff. Um, yeah. Uh, okay, so, um, let's see. Who wants to go next. Should we, can we hear from payments, give us an update.
Hi. Hi everyone, VJ hear from the payments Working Group on our side we are continuing to work on the API's, specifically or the open API specifications. I don't have much to report at this stage, so maybe over the next couple of weeks there will be some more progress. And we also reviewed the, the overall structure of the report the not report and the Specifications document. To make things a bit more readable. I think one element that we know that maybe I should mention is we will probably going to propose, you know, different scenarios for food, for the payments, you know, because we understand that different countries and different levels of development, you know, so for example the one one of the, one of the principles that we are going to suggest is to have a payment portal, you know where the information will be sent for each financial services provider afterwards needs to connect to the payment portal and execute. You know the different payments that needs to be made on their side. And in some cases, this would be for the payment portal if this payment portfolio exists so we will provide specifications for this payment portal. And in the end we will also cater for situations where you know there is no payment portal. How will this work as well as we will specify that. So that's something where we are currently working on now. But otherwise, the rest remains more or less same thing.
Okay, great stuff.
Um, okay, let's see, uh, who else Ingmar Do you want to give an update on registration. Yeah, sure.
Then we had a working meeting, we discussed a little bit about what we're currently doing with the registration and ready to building the lock, and the trunk Kumar said that maybe we should first focus on on register building blocks so we're hoping to get some feedback from him, what we have done so far so we can kind of start thinking of how to finalize the specification, we have the open API descriptions ready like comments would be really really good. Meaning that if those open API examples that the register building block is doing, are kind of up to the expectation. And
you want to. You want to just post a link to your open API specifications, just to make it easy for folks to go and look at them and give feedback.
Actually I did a, I did a merge in the GitHub, I'm not sure if it's finalized or not, but don't put it to the GitHub all those one one is Yamo file for the, for one minute a building block and the other one is JSON file for the registry building block so, But I can, I can send the link as well. Just a second. I will put the link.
While you're grabbing that link, can
I ask. Open API specs, obviously can be either YAML or JSON, do we have a, should we be doing one or another.
I think it's convertible, but I prefer Jason personally but Thomas seems to like more Yamo so we made a compromise one is
okay yeah I mean I think we definitely prefer JSON but, you know,
why not.
It doesn't really matter because they're isomorphic. But, you know, um, I, you know, I don't want to be dogmatic about it.
Well, I mean, we so JSON is nice that, in that it is a more rigid language. Yeah, so like there, there are sort of competing interpretations of yaml, and they provide different different features, almost. So like standard YAML is not really a thing, but standard JSON is completely unambiguous. You just have, like fewer data types and it's just very, I don't know it's very clear so I would, that would be my one little argument for JSON. Yeah,
it's definitely, definitely simpler schema. Um, okay, so yeah, so I see your pull request. This is the, this is what you're talking about right anymore.
Yeah, yeah, because I wasn't really sure where to put the catalogs so I thought let's do it once I'm done, I know, because there's this kind of local building block API. Yeah, I was expecting to put all my documents in the GitHub, but is it the right place to put it, or should we have registration and registry building block catalog separately.
You know I I've been thinking about this, I mean I think it's probably better to just have all of the have each what I think the way you've done it is, is the best way and let's just talk about this for a minute. Right, so what we're talking about is doing, you can share the screen so yeah so I can share the screen so I guess the idea is, you know, Do we put all of the building block definitions like open API specifications together in one GitHub repo, or do we have a bunch of separate repos. Right. And, you know, I think what Ingmar is doing is requesting that these get merged back from his fork, and I'm just gonna go ahead and approve that. And let's just go with that because then there's one repo, it's kind of like the master repo, which is the guff stack Working Group building bulk API repo, and we can have all of the buildings, all the all of the specs in there. Eventually, I think that's better, personally, because it allows for versioning and you know there's a central place where everyone can go. And if somebody wants to create a new one they just fork off of it, which is what we're recommending now anyway, right,
it's great for governance to big big cluster on there because you can actually have a pull request, and a body that is responsible for reviewing those PRs
right so I mean, I guess, uh, you know what I'm going to do though is I'm going to just, I'm going to make a, I'm going to I'm going to change my approval and I'm going to ask you to change them to JSON, just for the reason we just talked about. Um, alright. Yeah, I'm
kind of next to do what's, what's on our blue is, as we agreed in the in the telling meeting that we're gonna do some experimenting, can I got approval from from Uncle to set up a separate instance for, for gastech, so we'll have a registration system, together with the registry kind of building block system as a separate instance and connects them to the information mediator, the the thing that Alexandra set up. Yeah, and then we can see, my only question with this is that, who wants to participate in this, in the process of kind of setting up this new instance round now our new team member, given by given by unmetered,
you know, I think this is it, you know, I'd like to participate, um, however I do want to. One of the things I you know I asked for is funding for a gov stack specific hosting, right, excellent. So that was my second question right so, but that's, you know, we need to get approval for this whole approach that we're sort of, we've been doing anyway, so I'm you know I'm waiting for approval for that right so that I just don't want anybody starting up a DigitalOcean. You know, organization, and then billing against their own personal credit card like that's just silly. I mean I think we do need to have our own hosting. I mean Dale has some of this but, you know specifically for this prototyping. But, you know, any case, please invite me along, and, you know, that's one thing that I'm gonna, yeah,
I'm gonna wait the signal than I was planning to do it with my credit card. But if, if, if we're going to set it up so I'm going to wait on once I received the signal. Yeah, and then we're gonna organize a kind of an event, just to see on the screen, how to how to set up the system, what's it all about. Just as a, as an information. Yeah. Okay. And there was one other thing that we discussed with honey in the in the meeting to come up with some landing page idea just to show those different endpoints from the information mediator, but that's really raw. Raw idea kind of currently so I was just, yeah, visualize something really nicely so I don't know.
Yeah, I think we should we talk about that, I mean that's sort of, I'm imagining that would be sort of part of like the UI building block right where you have like the country logo and a list of services on the left and you click on the service on the left and the service loads on the right, something like that, but his response I
was Yeah, I was, I was a bit more technical wise as well, but you know the use cases are on there as well. Yeah, but I was just thinking that we have those different building blocks and kind of business people, they don't really understand that we're building some API specification, but what's, what's in it, or what's inside it so let's just put those API's, on, on one screen and say that this is the payment building block, this is the API with swagger view or something to do here. And if registration building block gives the user or sends data moves from one database to another and so on. Yeah, something like, not so technical but more like kind of user, user understanding.
Yeah, so I
guess, though. Okay, but this kind of portal is available from Mexico. It's called Miss.
It's true when we were thinking that, just to have this. This kind of landing page or, or live in nice looking and you don't have to log in actually there, but I'm not sure how far is missing, so we can try that out as well. Yep.
Any final
product. Okay, okay, well, so I think these are you know more in depth conversations we should be having. So, um, let's just get, I think we're pretty much through with a stand up though. Um, so a lot of exciting progress. This is, this is awesome. So two things that I'm going to note, Just so everyone knows that all open API specifications should be published as JSON, and that we will be doing.
Yeah, we'll be merging all of those into the master repo.
Thanks. Yeah. Yep. Hello. I had one important resource models are required. Some of them have put into such models for specific use cases. In the information specs. Yeah. For those who don't have models.
Yeah so,
experiences and predictive models.
Yeah, and those should be in JSON schema format. Okay. Okay, great. So yeah, I noticed that as well. Just as a key point or key decision. Just so everyone's clear. Thank you Ramkumar. Um. Okay, so let's see, um, great progress. Uh, yeah, so, um. Alright, so let's see. So I guess we don't really, I guess we're not really doing, you know, does anybody have any progress on their PowerPoint presentations I mean, honey asked for those, maybe it's about time to think about updating your PowerPoints so that there's a simple executive you know an overall view of what your group's been doing. Um, and then a reminder to use the building block definition template if you're not already, I think I know everyone on this call is reminded write down your significant changes and decisions and a log into the header and your billing Buck definition template, everyone should be doing that. And then, a reminder price source for all your images and diagrams. so ideally draw that IO are web sequence diagrams that can be edited and evolved. I'm wanted to review the milestone checklists to just quickly so I'll just share the screen. And look at this. So, so let's just go quickly through so payments. This is great. So thank you so much. I can see you filled in these target dates, a lot of stuffs done already and this is in progress. So this is really helpful to make sure everyone understands your progress. So registry, let's take a look there. Um, so, uh, so please make sure this is accurate. Same with registration, please make sure this is accurate. If it's not. Okay, and then workflow, you know, consider
that I think one thing, one thing that he could hear. Yeah, we need to extend it is also one more column, which says, reviewed by architecture team and think,
Oh yeah, okay well that's, that's not a bad idea. Sure, I mean we could just add that over here so we can do that. Um, I like that idea. So just you know, a reminder, you know, for information mediator, um, you know, update the dates updates what's done and in progress for, for, for everybody. Okay, so just please. I'll just put a paste a link so that everybody has easy access.
Okay. All right, let's see. Going back to the meeting minutes. Oh, not those. These meeting minutes. So, um, alright so we can work on the logical process outlines and flow diagrams. Okay so this is important so reminder to kind of, so we have this logical process blueprint document, um, so ideally. Everyone is linking any of their diagrams like even if they're kind of specific to your building blocks, especially if they're specific to your building block, please, you know, add the, you know at least links to your flow diagrams if not including them here. That would be really really helpful. So a reminder to do that, just so we're not missing any.
Yeah, so I'll just post the link. Yeah. So I mean what the idea here is what's the
what's the link to that route. Right, yeah,
yeah I just posted it. So it's in A, it's in the chat for Jitsi. Um. Okay, so let's see what else, uh, uh, oh yeah so I wanted to check in with everybody and just see how it's going with the discourse. Right. So is everybody able to use discourse Are you are you using it. Any blockers in terms of using it, so I can see that there's information.
Just a good question here. I didn't see the meeting minutes catalog. Was it possible to do it myself or is it something that somebody needs to do.
Yeah, somebody, an admin needs to do it. So I'm going to go ahead and make a note.
So, okay.
So I'm going to do that. So thank you for reminding me. So I just want to make sure you know and also just point out that every building block, you have in here. You know, for instance payments, you should even have a list of key resources. So please update these key resources. I went in and created one of these at least for everybody. So, uh, yeah, if they're missing key resources they're
able to just create one more. I don't know what the folder directly export this milestone deliverable chat.
Yeah, well it's it is kind of like it. Yeah, so it is listed. Um, it's just like not necessarily super easy to get to
just close that in the main shape quickly
do that.
Yeah, so, uh, let's see, um, and then I guess the whole, the idea is to have this the page. Now, So there's this guff stack documents and resources. And the idea is that everybody will have, you know their key resources listed here. Um, so this is really important so I guess, please update this document. And I'll post a link. And if you
have, so I'm just gonna post a link here next post the link here,
so I'm going to go ahead and update. Well first of all let me post a, I'm gonna post this to chat.
And I think it's so that's there. So, and then this actually has, Um, does this have a checklist, no it does not. So, just so you guys can you guys can see my screen right, so it's, uh, oh geez I think I have to sign in. Um, maybe I have to do that in my other browser, because I don't have my credentials here. Um, okay, so no anyway you can sign in, and then you can just, you can basically edit this document right. So, um, once you do that you should be able to edit the document, I hope. And so I'm just going to edit the post. And then, for example, we need a link to this checklist, right. So I'm going to put that right at the top, just to show you guys how it's done and this is sort of a, I'm just going to put it like this and then this uses some sort of markdown, I guess an easy way would be to use this link right so then the list is this. Okay, so this is like the. Yeah.
I'm just gonna put that there and then now there's this checklist for all groups to keep updated I'm going to save my Edit, and then it's just that easy. Right, so that's what I'd like everyone to do and just make sure that the key documents are listed here on this page. Um, so I think this will really, this will be really really helpful.
Let's just click on that, let's see if it opens up.
Yeah, I'm sure it will. So it's just that easy, folks. Okay, Cool. So, um, reminder about that, too, please update the links. I'm
sorry, a question marks Yeah. Maybe you do mention it. We can retain it. But how do we log in, We need to ask you for a username and password.
Yeah, you should have an account. Hold on, let me just, let me see here. If you don't have an account, let me invite you. So.
All right, so, uh, how do I even do that. People invites. So, um. Alright, who wants an invite. So just type your email address in the chat, I guess that you want to invite to. Or hey, how about this, I'll just post this link and then you instantly get access to the site.
Whoa.
Max Yeah.
Oh. Only thing. For the most part I've had a good time was discourse. Yeah, but that the only thing that was still sort of unclear to me is whether, whether the email to discourse is only available for the first message on a thread or whether we should continue to like CC discourse, and I saw I even saw Steve had a note about this at some point saying like, FYI discourse works well when you send a single message to it but it doesn't work very well.
Yeah,
so like, basically publishing replies to a thread, you know if that's still the case or if that has changed.
I do not know if that's still the case, I suspect it is because I have not yet changed. So, yeah,
no worries, no worries.
So let me add a note though,
it I suppose it just depends on the intent like I, it would be kind of cool. If you know, all of our emailing back and forth for sure is done out in the open, you know, but it's also you know it's it's also totally fine for sort of, if I send a follow up email after a working group session, just on that initial follow up email it CC's discourse. It's not quite as exciting then because then sort of the conversation and each Working Group on discourse is filled up really just by the working group lead and not by it. The participants are going back and forth, right. Okay. I don't know but I'm not sure what the, maybe the answer is just to get people to actually sign up for discourse and then do it in discord rather than doing it by email, but,
well, I mean, yeah, that is, yeah, I mean, yeah, I don't know the answer, I'll follow up.
Yeah, that's that's cool that's cool I just wanted to float it get it get it in the nose.
Yeah so okay so that's a good point right I mean, so the one of the limitations with discourse just so everyone's clear, is if you're ceasing the email address, and you should all have email addresses is everyone aware of their email addresses, um, thought, yeah, so here they are. They're all in here. So I'm here are your, you know,
this is a reminder. Okay so you can just CCA these email addresses and your whatever you write an email, at least the first message on that unique topic should show up in discourse. So the issue that Taylor's pointing out is if you replied the replies of those emails are not showing up in discourse. So, that's something we need to fix but at least you can try that out. Um, okay, so what else, um, any, any other, you know, questions, comments, concerns that folks have anything we're missing here.
I think Max, we started with this discussion on terminology, I think two things one is on the terminology. And the second thing is continuing on this discuss thing. So if this, if these various groups and especially new guys have come on board now. If they were to deposit some documents, this time around.
So is it possible for us to just give them links to a specific building block, sometimes up in some folders or something like that. Yeah, so
exactly so I mean I think our documents right away. Yeah so, I mean there's two things right so there's the Google Drive. Right. So right now, everybody's kind of standardized on the Google Drive. Um, so I mean I don't really feel comfortable 14 people to use Google Drive. But that's what most people are using. Um, so, I guess everyone should be aware that almost all groups are, you know, and I'm just going to post the link here. And I think everyone's using this right.
Yeah. Yeah. Hold on.
Okay, so there's the GOV stack route folder so if you go look at that. You can see there's links to milestone deliverables, it's got everyone's documents right but, you know, so there's an issue with this though. I'll show you what you know so so first of all, I mean, people should be publishing their stuff here. I'll just share my screen, so it's easy for everybody to see but it's a little bit messy, like for instance if I go into like the architecture group. There's all this stuff in here that maybe is not super relevant including, you know all our PowerPoints and everything. So that's why this gov stack documents and resources is so important because this should be just a subset of things that you want the public to look at, right. In addition, though, we encourage everybody to publish, like we have all of their meeting minutes in here. Right, so you can go back and read all these meeting minutes for the meetings that we have, including this one. You know the use cases we're publishing here. Right, uh, also, you know reference documents and then, you know, other key documentation, we're just putting in here. As it's been evolved, but then we tried it, we make sure that this is updated with just all of the really key documents right it's like, and links to resources also. So that, you know, honey or someone else can go and look at this and understand, you know, which things should be looked at. Out of those folders. So
I saw the Google Drive version is more like the scratchpad right, that people are.
Yeah I mean it's got, it's got everything in there
is the. If I'm electricians,
yeah exactly so this is sort of like this is more public right because over here I'm not even logged in right. Uh, but everybody can see and access this page even if they don't have a an account on discourse. So this is sort of where you publish this is the first place to publish your specifications. Right. So, whereas the Google Drive, you can put whatever you want up in there and then you know that's kind of what we're doing so we got, you know, the TM forum REST API guidelines and anything else that you need, you know, other whole bunch of other reference documentation so you know this is the I guess the idea is try to keep your you know your Google Drive very comprehensive. But then also, you know it's good to link to it from this go SEC route so other people can find it, but you know you should have an organized set of just the links up here. Right. Um, so that's really helpful. Um, and I guess, you know the other thing is, you know, we do need to wait as we do this formalized publishing process which we started out with security, There's actually a PDF file. I guess this is a, you know, another important point that we should cover is that, uh, let me see here, the actual initial draft security specification is a PDF file. And so the reason for this, so it's published on the ghost Global website. The reason that we're doing this is twofold one is so that if a Google Drive. Access is lost or somebody, you know, right, this is sort of the definitive place I mean the other thing is that you can publish this, you can refer to a specific numbered header. Right. So you can say section 6.1 dot 15 in the security building block definition one dot O dot one. Right, so it's got versions here. So this allows you to anybody to refer to a specific location writer specific header inside the document, and then the documents are version so I'd encourage everyone to refer to the PDF. So in your, in your document in your building block specification. If you're linking to. For instance the. Everyone needs to be linking to these cross cutting requirements right so you can just say, Section five, this URL right is kind of what we, I'm sorry. Section five of this URL is a what folks should be referring to. So, and I guess that's this one right. So, and the reason for that is that this you can you can print it out if somebody had a PDF printed out paper version of your specification, and they had sitting next to it, a printed out version of the security specification, it still works right. Section five section 5.1 You can refer to those and the version of the document. So, as people's as folks specifications are, you know, ready, let me know and we can try publishing a draft up on the website.
That's a very good idea and I have a proposal, let's do the same thing with architectural this architecture paper because, yeah, we need to refer to cross cutting requirements in the architecture document Oh, yeah. Good
point, good point. Um, so, uh, let me just add this to the key decisions, a max architecture.
Okay. I'll just put a link to that building blocks verification, okay cool. Good point. That's something that we need to do. And then I'm just going to remind everyone, you know, um, Okay, cool. All right. Great. Any other questions or comments.
I think we got sidetracked I was just saying about terminology. Yeah, It started that discussion in the workshop and I think it's important to do at least two things. I'll send out a mail, capturing my thoughts on it more in detail but then the point is this. There are terminologies which are local to various building blocks. And then there are terminologies that he says building block is referring to some, something that it borrows from another building block, and it has got to be the local reference of that building block, whatever terminology is used. So there may be some cross referencing requirements, I'm seeing as I see different documents, especially tomorrow, when there are one building block is talking to another building block for and getting back something. So terminology. Local terminology, cross referencing, and also a global Glossary of common terminologies which has like a cross functional requirement we should have a cross building block terminology common foundational, which everybody should be on the same page. And then, in that in that bundle, I see that, you know, we need to define a few jargons like like we use cases that tell me scenario, we are using so many words which are interchangeably being used. Yeah, so it's good to nail that down in the global glossary.
Yeah, so we do have that the global glossary. You know we did put one in here but I think we need to update it right. So
you went from. Yeah we needed updated some new jargons are probably,
so there's like this terminology section so this is how we've done it but it's kind of, you know, there's a bunch of stuff in here. That is kind of missing so you know like, I'm just gonna throw one out there and say like, so I
add to this one and start in writing. Well so that we can analyze. Yeah, this is the set of global, global terminology, right.
Yeah, exactly. So this is global terminology so I guess we can add stuff, you know, anyone can go in here and edit this and then we can accept the comment and
good to copy this link Max. Yeah, so I'll
just say you know like hey you know folks please, you know, update. Yeah.
I think that, let me just make sure that it's actually jumping to the right header. Yeah. Just so folks have that. Okay.
Yeah. All right, cool.
Good points. Okay, anybody have anything else they want to cover. All right, great. Okay, so, um, one more thing that I think maybe I'm going to just review quickly, is just the previous key decisions. So, you know, again we published a draft specification. So everyone's gonna update their links, so again I'm just going to, you know, copy and paste that one. So, so we got the same, you know, so we do have a single page here that has all the links so that's great. Um, and then we talked about publishing a draft information mediators back. So, uh, you know, that's something we want to do. Alex and Taylor, think about that. Um, we can talk offline about that. I think I yeah I think we're good. Anybody have any other questions, comments that they want to, or concerns they want to raise.
Next whenever you're fixing these weekly meetings for the new groups.
Hello, I mean I think we need to reach out to the leads and figure out what day is going to work, I mean I was thinking like maybe Wednesday or Tuesday or Wednesday. So, but, um, you know, pretty flexible either Tuesday or Wednesday it would be best for me. So I'm just going to add a note that we're going to reach out to all the groups.
Okay, cool. All right, anybody have anything else. All right, great. No. Thanks so much everybody for joining. Okay, and, Well, we'll be in touch separately. Don't hesitate to reach out if you need anything. Okay. Yep. All right. Bye everyone.