 Hey, John see if that works. Good morning. Hey, how's it going? You know, I'm actually traveling this week. So Wow, what's that like? I haven't traveled in ages It is Hi to cereal Yeah, I mean, I'm only in LA. So I guess that counts as a third-world country, but man Your perspective there's some people I'm sure love LA Yeah, yeah, all the people I know who live here. Yes Californians definitely have their own little perspective on the world But I should stop at that since we're being recorded Yes, well, I call it la la land, so yes Yeah It's the funny thing steady studying the you know from a neuroscience behavioral science perspective The extremes it's it's literally the same brain mechanisms just reacting in different ways And but the logic is the same the extremists it's a it's a weird creepy thing I read a little when you talk about extremes, but what in particular you're referring to so if you think about the the most extreme people and like on the left versus the extreme on the right They're they're the mental patterns the logic Illogic, however you want to call it. They're they're they're subjective justifications They're the same it's just the path they take in their logic to justify it and what they react to emotionally Are are where it differs but the actual subjectivity and the brain processing is the same creepy thing Yeah, because I've often heard people talk about how The the political spectrum actually is a circle and yeah, so that's interesting Enough of that fun stuff. Are we talking about politics before? No, no, no, no, not specifically just this the concept of people's perception of it. How's that? All right, so that was David who clearly wants to talk about politics now Don't not very work. No Tommy either Yo Christian Hello, and then Timur Hello, I will be happy though when the whole elections over just because I'm just tired of the the text messages Telling me to vote and the emails From from both sides it which is really fascinating that I actually get from both ends I have no idea why you think I don't I get it from one side, but nope I get it from both It's weird And and all the people who want to influence One way or the other yes so Hey, Doug. Oh, hello. Hey Kristoff. And let's see Brian. Are you there? Hey, Doug, hello All right I have kind of a short of agenda today So hopefully we can make it quick However, we do need to start talking about the interop doc. I did make a couple of changes earlier today just some suggestions We do at least have something to talk about but I didn't realize it, but November 2nd is coming up really fast so Simon are you there? Hello, gotcha. Thank you. Hi Klaus. Hi, Doug How are you doing? Great, you're good. Good. Yep doing good Hi, Ginger Hey, Doug And Manuel, are you there? Hi. Yeah. All right. All right. Let's give another minute or two I think we have somebody new in the call Lou Dang Are you there? Hi. Hello. Do you want to be associated with a company? If you don't have to if you don't want to and just just for roll call we tend to associate with Oh, I'm from Google. Ah, okay that one I can spell. Thank you. Thank you. Yep And Slinky, are you there? Hello. Hello Hey, Doug. This is Mark. Oh, hey, Mark. How's it going? Awesome. Good. Oh, hey, Mark before I forget The CNCF sent us a note asking for a Paragraph or so if we wanted to give them a status update for some for something they're doing for coupon I was gonna write something up But I was gonna I wanted to send it off to you just to do word smithing and stuff like that So keep an eye out for a slack message or email or something for me later today. Okay. Cool. Thank you I guess I missed it. So I'll look in my email for it. Yeah, it's I can't remember when they sent it But it was a little bit ago. I just yeah, it comes out on the if you're on the CNCF maintainers email Distribution list. Yeah Yeah, thank you. Okay, cool. All right, Eric, are you there? Hello All right And I need to show you there Hey, Doug. Hello. Give me another 30 seconds or so. Don't get started Hey, Ginger, did you notice that they reopened the office hours thing? Oh No, I didn't see yeah, I got lucky because I completely missed it the first time so as you said almost all the time slots were basically gone except there's like a Late late Friday afternoon when still available. So I thought okay fine. I'll I'll grab that one and then Almost immediately after I signed up for that I get some emails saying that they reopened it and I went back and checked and I got really good times So I ended up in the Friday one. So yeah, you may want to just double-check in case you take good times. Yeah Thank you. I got lucky that I messed up. So there you go All right three after why don't we go ahead and get started. Let's see we have 17 people. All right, so Just a reminder. I don't see Lancer Scott. So I can't nag them about the AI. So keep moving forward Anything from the community people want to bring up. That's not on the agenda Okay, not hearing it. So as I mentioned just now, we do have office hours I was able to snag some I think some pretty good times As we get closer to the date, I'll be looking for people to volunteer to hang out there last time it was fairly Easy, I don't even think we had anybody show up. So we'll maybe looking for one or two people just to hang out there answer questions In case people do show up Be looking for names later to be thinking about whether you can take either or both of those times be appreciated But it should be light duty I'm trying to think it was anything else for KubeCon that we need to mention. I can't think of anything. So I did submit the video and PowerPoint slides for the cloud events session that Clemens and I did and Later today teamer and I will be recording the one for the service working group session and then we'll submit that today And I think that's it in terms of our sessions for For our organization Can anybody think of anything else worth mentioning that I'm not mentioning that the group may need to be aware of Okay, good not hearing it SDK call none this week, but we will have a interrupt call immediately following this one With with November 2nd coming up. We really need to get on the ball in terms of filling out the The scenario doc as people know what they want to code to I did make some suggested changes Right before this call So we do at least something to talk about and as a reminder, we'll start that call immediately following this one No later than 1 p.m. Eastern, but probably earlier since we have a short agenda today All right, and Timor anything you want to mention relative to the workflow subgroup? Oh Hi Yeah, for the specification and the we're currently discussing The the function or service and location definitions. We're going through them and rewising And also we're moving forward to to hopefully have the A new release by coupon, so yeah, those are the two things. Thanks. Okay, any questions for All right, cool. Yeah being able to announce a new release at coupon will be really good All right into the PRs before we jump into that any other topics we want to add to the agenda before that I've already forgotten about or anything really important All right, let's jump into some real work then PRs Manuel you're on the call. Would you like to talk to this one? Oh, this one's easy. You want to talk to this one quickly? Yeah, it's very easy. The Jason schema doesn't follow the specification as you can see the data schema definition has a min-length of one which makes it Required parameters, but the specification says data schema should be an optional parameter. So Yeah So just removing that field any questions or concerns about that seems Like a typo to me. Actually, I think this If you look at my PR this it updates this so min field min length one is correct because that's that says if it's specified then it has to have a length What the change should be is the type well, I think this is fine actually So is there a field in Jason's scheme of the indicate whether it's optional or not? So there is a required section I think above this which doesn't have data schema in there. Ah This just means if that field exists, it must have a length if it doesn't exist. It doesn't matter So the data content type can be empty. Sorry The data schema can be it should it should not exist in the payload with an empty string And that's what this line is saying. So this is correct. Yeah Catch Yeah, we had the same problem discussed a few days ago and actually the format you or I will make sure of the validation anyway So an empty string would not comply to the format you or I So if you want to omit it, we need to remove the data schema Property completely or we allow null values I have a follow-up to add except null values too. So that will It'll solve that Yeah, but men well. Oh, just thinking your hands up I think it would be better to keep the main length one because in the latest Jesus schema draft Format is an option by this Okay, so men well, would you agree that we actually should keep it? Okay, I just noticed that all the required fields do have the main links one and the ones optional do not have it So I thought this was an obvious one, but We we'd also want to add no value acceptance for all the optional ones, right? And maybe then the main links would apply to all or none of them Having this field Scott, do you want to take a look at your PR right now just since it's kind of related Yeah, sure. I think the the mistake is that we Need the min length one on all fields that the spec says cannot be empty if specified So Did you you did modify? Yeah, you're not for the jason schema. Yeah So you added null to all these Because they're optional, right? Yeah, I think the Data content type def needs a min length one to do that as a follow-up So does that address your concern minimum? Oh, yeah, go Yeah, so now actually I thought that we had the discussion on null values And which means we can have them. Okay, so not having anything I think I'll understand. Okay So then yeah, I can have a data schema def data schema that has I don't know this the data content type with a length of zero And that is not being null or absent from the spec. Okay I think Scott's saying that this one is missing a min length equals one But in general we need a min length equals one because no, we were not we don't allow empty strings That's right if specified right exist in the box The payload or in the envelope then it needs to have a value So I think What we're saying is this PR should be closed This PR at least relative to this stuff needs to be accepted But a follow-up PR should admin length equals one to do this thing Right Scott Yeah, I think that's true Is that also true for the time definition? I think that's true Is that also true for the time definition? I think because the date time format I think that requires it to be non empty string I think If we if we want to be consistent we could do min length one Yeah, we should we should do that again because in the next Spec of just a schema This is the format is optional. So even if there is the time The body data can you can tell you look I don't know anything about formats so Okay Hold on Okay, so let's let's do this one at a time. So going back to this one. Is there any objection to closing this PR with no action? Okay, so Since Okay, no objection we can close that now and that since let's go ahead and tackle this one first So Scott, why don't you talk to this one overall? Let me hide the comments for a sec Let me just talk to this one overall So the general idea is that this only changes how we interpret the wire format not it doesn't change anything else. So it's really about Pushing the The cloud event shape onto the wire as a JSON object and pulling it off but not the object at rest So like not the in-memory version of it or the conical form And then I added some examples of valid on the wire cloud event objects Yeah Yeah, so this makes it perfectly right here And then yeah, it's just this is just That's the prettier right stuff. Yep. And then here are the examples that you talked about I'm sorry Remy. You're really hard to hear. Can you speak up? Yeah, yeah, sorry one second Yeah, I was just saying sorry Much, much better. Thank you I think there's just one small typo. It's my typo week in equivalent. It's written equivalent in this PR For what I read like you should go Like Yeah here if I If I'm correct the it's the second I should be a Scott Scott you okay with the making that change I quit Well, you know what what's nice about this is that opens the door for us to say hey why you're in there anyway You can add them in length. It was one stuff. Yeah, sure. I could do that. No problem. Okay. Thank you Scott Good catch there Remy Yeah, it's just my day My week and I have a small PR with another type Okay, a man. Well is your hand up. Is that older now? Oh, so that's old. Okay. So I thought okay So let's see if there's anything else here worth talking about that was just prettier things and then we had down here So does everybody agree with these changes and and of course the addition of men length equals one on this one and Time-deaf I'm assume Scott you'll check the other ones to like based of 64 Yeah, I need to double-check that because it might actually be valid to specify it but not put any value in there because that would just be an empty buffer Okay If I'm assuming that if all that if Scott goes ahead and adds the men lately was one of these things that everybody's okay with that We can prove that here. However, Scott if you find that there's another gotcha that we're not thinking of We'll hold off till next week to to approve it if that's okay Sounds good. Okay. All right. So anybody else have any questions or comments on this one with those changes meaning the men lately was one and then the the I to a letter change up top Any objections. All right, cool. So So we don't need to follow in PR. I'll fix that in a minute, but all right, cool All right, so camera who wrote this one Anish cool All right, let me Get a time that for a sec All right, Anish would you like to talk to this one? Yeah, basically sums up our discussions in the previous weeks where we were talking about having certain Additional fields in the spec in the webhook like I guess And then we decided that we really don't want to get into the security business at least in terms of our specifications I just added it into primer that that's a void when the specific authorization principles at least as part of our spec and let the implementer Take care of these things as extension attributes as possible Okay. Thank you I know there's one comment and then I'll get to that in a sec, but any questions or comments about the overall direction that he's going here Any concerns with adding it It's it sounds a little bit like closing the door on security You mean if we choose to add it later Yeah What entirely I think the idea was to give a little bit of guidance So this is stating that every vendor has said different authorization model Hence governments will not now or in the future as the impression I get from the text Specify any authorization Would it make you feel more comfortable if we said instead of will not it says something more like currently does not or something like that Because I think it would yeah, okay Because I think technically what he wrote here is accurate the spec does not or will not do that Yeah, but it and maybe it's the word will that's throwing you as implying a future statement So if we change that to does not would that help Yeah Anish would you be okay with that I would really expect Clemens to pitch in over that Because we It was like a very clear thing from his side that we do we really want to get into security business part of the spec But yeah, I mean I'm all right with it Well, if you'd like what we could do is do whatever word Smith me one on the call here And we can say it's conditionally approved But you want Clemens to weigh in first and if he's okay with it then we can let it go if everybody else on the calls Okay with that Yep Okay, so in that case Yeah Yeah Yeah It only talks about authorization model I think we were talking also about the integrity of the event Because whenever we talk about signature there are two things right the standard authentication comes and then The integrity of the Payload I Mean The data integrity is still kind of falls under the authorization principle right because you want to check whether the data is correct or not as part of Update process. I think that's one of the steps for authorizing the right update operation. I guess And I always thought authorization is more about access No, that's authentication authorization No, authentication is not about access authorization is about access and What we are talking about is the integrity Okay, I'm up for options and opinions Well, I so Sanjay you're suggesting that we probably need to enhance this text to include the integrity side of things to say we don't deal with that either right Yeah, if we are not going to do yeah But Anything I would say you know Extended for the integrity part also And and Doug, you know if if we have to let is there an Away where you know the course pack would not say anything about The integrity of the event but if you want to give Example where you know there are use cases where in webhooks you want to send event out and you want to offer You know And up Show an approach where how we can one can validate the integrity of the club event payload and event envelope That would be some Is it possible to link some documentation from cloud events site for that those kinds of use cases Or we would not even do that So I my personal take on it is Actually hold on a minute. Eric's hands up. Let him go first Eric. Go ahead. Why don't you go ahead and have your talk? I'm gonna take us on a different thread here. Okay. Yeah, I was gonna say so my personal point of view is I think It makes sense for us to talk about things like authorization encryption or or Integrity and talk about how we're not going to touch that stuff When it comes to pointing to other things that people can leverage as an add-on to our specification I think it's okay to talk about it in general terms to say hey Just because we don't do it that is doesn't mean you can't add it I just get a little bit nervous about pointing to Particular things because I don't want to look like we're endorsing one particular thing over another Now we if we include a list of things to say hey, by the way, there's x y and z out there And and it's very clear that we just happen to pick a random set of three things then that that would I be okay with But if we only point to one that would make me more nervous if that makes any sense Okay, got it But that's just me. I don't know how other people feel No, I understand the argument about endorsing part of it. So Yeah, and and also from the data integrity point of view. I think because somebody talked about it act down the line So it completely depends on what fields you want to send as part of your data payload, right? And over there you can always send it at which shows But still does the job at least in my opinion, but yeah, let's let's also discuss this again in detail Okay class your hand is up Yes, so if I recall correctly in San Diego, we even had the integrity topic on our list of potential activities for the future So I think it's good that there is this distinction between authorization and integrity Okay Oh, lots of hands now Eric, you're back on the list Yeah, I just wanted you to be able to speak your piece. There's two comments that I have and one is that Mentioning vendors seems like Maybe a red herrings not the right word, but Not quite as direct as it could be because it doesn't say anything about say the the open source or you know other kind of standardized implementations that there might be to solve for this problem But the other pieces that I kind of assumed and and I've been a bit lazy so I apologize, but I kind of assumed that when I was working with a Getting done that they look into the primer because I'm quite certain that there's a piece that addresses some of this in there and I would have expected that to either have been modified or removed In preference for this, but anyway, that's my piece I was actually wondering whether we already have something in this Top already, but like you I got lazy and haven't actually checked so well, you should do that now I thought I did, but yeah, I probably missed it too While we're bringing it up Manuel, do you have your hands up? Yeah, if I record correctly, we were talking about that Yeah, I think that's a good point Yeah, I think that's a good point Yeah, I think that's a good point Manuel, do you have your hands up? Yeah, if I record correctly, we were talking about the signatures and signatures can be used for syndication or authorization But I think the integrity check was the use case being discussed so apart from the authorization that is done with the web book And using this signature for the integrity of the message we were we discussed like three options either we wanted to Also save the integrity of the cloud events envelope in which case we said that this is not a model for cloud events I think So it's out of scope there, but then there was also the idea that maybe the data part so it could be entirely left to the application That is within the structure sent in the data field Or if wanted to write an extension that carries the signature and the envelope for the data transmitted in the data field So I wasn't sure if Clemens had said something on the consistency of this approach, but I think there was something that Scott had suggested And when we said we wanted to give some guidance in the primer of how to do that, I thought this would sort of be put in the text like a user could choose to solve this entirely at the application level And maybe if we say it shouldn't be integrity of the envelopes then this may be a decision to to say this should be excluded from future attempts. Okay, Sanjay your hands up. Yeah, I agree with manual I think the out of those three approaches right I did write a comment that often you know you have to sign because the cloud event envelope has context, which is important when you sign the payroll. So in my opinion manuals, you know the third approach only makes sense when you are doing the integrity check. But I agree that we should list those three things in a, you know, separately, and we shouldn't say that, you know, you should just however you want to sign the payload and you, you know, go ahead and use whatever approach you want to use. I think parts of the envelope are important. Whenever you sign the payload. So our guidance should be kind of, you know, include that part that you know we understand that part of the envelope is also important when you sign any payload. And if you want to do it, you can do it this way and I'm not talking about the course back. I'm talking about the other revenue where we know we want to discuss this use cases. There we should take all three options and you know, provide recommendation accordingly. Okay. So, so you've got a lot of feedback. How would you like to proceed? I would like the comments to be on over the PR so that I can address on them and then how I see is at least currently we probably don't want to deal with the integrity issue data integrity issue right now until we start addressing it as a topic. We simply say right now that currently we don't mandate it. And then we're going to address this issue overall once we try to pin down the data integrity topic in general because this completely deals with us not having a mandate towards an authorization principle or a security model at least right now. And then we would probably address it. It's not like we're not going to address it but this is something I think it needs a bit more deeper discussions down the line. Right, but I want to make sure I understood what you're saying there. Are you going to update your poor request to make it clear that basically we're, we're not touching security and that includes authorization integrity checks and yeah, I would say so. Okay. Okay, so we're looking for an updated PR then. Okay. So people, please add your comments to the PR if you have not done so already. So, so I need to have all the feedback written down and get your thoughts out there. Okay, and also another last thing about authorization was authorization. Yeah, I noticed you changed it here. You didn't get to hear though I noticed that and then there was a comment about how the the e here needs to be capitalized. We can work on that later. Those are minor things. I think that was the only comment and then let me show just make sure. Yeah, okay, cool. Okay, so yes please everybody leave your comments on there, even if you set it on the call here please leave your comments in the issue itself, so that so I need to remember it and and take it into account as he adds the text. Okay. So thank you very much and use for that. Cool. All right, so let's go back over here for a sec get ready you. Let me close this refresh here because Scott just said he updated it. All right, so let's go and see what he did. All right, so here are the new edits in length one knows I think we're there before mid length one here might be easier to just see the one single diff. Oh, do that. Is that going to do it or do I have to click on the right hand side, click on the hash. No, okay. There we go. So we got the a. And then he did this. Does that look right to people based on what we talked about before. I read the spec and it seems like data base 64 as an empty string is technically valid base 64 encoded data so I left it alone. Interesting. So that's a requirement that it has to have a mid length in the spec. Any questions for Scott on this one then. Okay, any new objection to approving it. All right, approved. Cool. You got all three. So let's see closed. Can't type today. Close with no action. All right, cool. All right, that's technically the end of the agenda. Are there any other topics people would like to bring up. All right, in that case, before we jump over to the interop call, let me just do the attendee list for the folks who do not wish to stay on. Remi we did hear you. Colin are you there. I am a dog. Hello. I'm here. Excellent and Lance. I'm here. Excellent. Anybody else that I missed for the roll call. I got everybody. All right, in that case, if you're not interested in the interop for no second, you are free to go have a good rest of your day. And we'll start up the interop call in 30 seconds or so. Thank you everybody. All right. So, it seems to me based upon our previous discussions about things like maybe we shouldn't tackle importing and exporting or synchronization between discovery and points. I was thinking that maybe the circular one, while really, really cool sounding might be a little bit more advanced than I want to tackle first time out. So a little bit before the call here, I started writing up a very simple user flow here. So user queries discovery and point with the services, they select one. Maybe they'll only look for the one that supports a speed push delivery. They subscribe to it. They verify the script description looks right by doing it if you get to the subscription. They verify that they get at least one event because the service is going to be required to send at least one event every 30 seconds. So they verify they get at least one. The user when they're all done, they can delete the subscription and then verify they don't get any more events, ignoring any possible things already in flight. But I was thinking if we can at least do this simple flow at least test, I think some of the basic stuff or stuff in the spec and it does do discovery spec a little and a little bit of the subscription spec. If we wanted them and go a little further and say okay let's start adding some filtering, possibly update the subscription and get if we really ambitious some non ACP plus push event delivery. But that was just some initial thoughts that I had, because I feel like we needed to fill out that the document a little bit better in terms of what the actual scenario is going to be. Possibly an easier instead of trying to set up some sort of circular dependency we, we make it a star map where every other subscribe every other endpoint that is participating aggregates up every other participant. You get loops that way anyway right because if if I'm importing you and you're importing me that's that's a loop, and we have to figure out deduplications. I personally I'm not necessarily against it, other than I got nervous based upon a previous conversations about whether import is fully defined in the spec. I think it doesn't need to be though right I think we really need to pull back all of the management APIs that have been added, and just wait and see because I think that's that should be up to the implementation detail. I don't think the specification needs to define how to aggregate stuff we just need to talk about what the endpoint provides and what the data means. Again though, in this model where there's this aggregation going on. How does information get moved from one discovery endpoint to another. I think it's an implementation choice of whatever is going to aggregate stuff right like this is a. This is a feature that the downstreams implement, and they to the to the upstreams they look like just another consumer asking for the discovery endpoint. But to them like to to the down to the sorry I always get the upstream to downstream so the for the upstream service that downstream thing. So the aggregate looks just like another client to it. So he's just doing a series of gets just doing gets. Okay. Now the thing that's interesting that doesn't have to be written down in the spec but could be in some kind of primer is that if you are a discovery endpoint, you can also implement that the the subscription API for the catalog content of the discovery API, which is very tricky. And it doesn't have to be specified right like that's just something that you can do if you interpolate between the discovery endpoint spec and the, the subscription API spec. Can you do this. Sorry, go ahead. Yeah, go ahead. Yeah, I think I think what you're describing there sounds sounds nice. And it certainly would be easier than a, then, I think what I was had in my head. Can you actually just replace this section with what you sort of describe there. Sure. You paste the link to this doc, I think I've lost it. Yeah, it's in the main agenda doc when they put it into. Hello. There's the. Thanks. Okay. Okay. Now. So Scott's going to replace this with his simplified version, which is good. Does this stuff sound okay or does this stuff. Not sound okay. I think it's good to. Yeah, for me, it's good to try to do that to make it more concrete. And to kind of follow on Scott's thoughts. That was what I discussed a bit yesterday with you with my ID is, but maybe I'm wrong and I would be happy to be correct if that's the case is in a way we kind of the way I see it is if I had something in the middle that will basically use a discovery to add and subscribe to several services and then give me the ability to have one main discovery in the middle that basically link to new service then as a 90 and mean I can add new services into it and for my old companies that will only be able to do it with discovery service that. What the other form through all we define. And make them available without him to think about anything like basically just have like the new GitHub. And that's the kind of. I think it spawn a new just project that is cool. I don't know, even gateway or something like that that will then have to implement subscription and and the discovery service, but that my thinking of implementing the whole spec. I plus one I think that's, that's exactly what I'm thinking. We don't have to specify what the gateway API is though because that's an implementation of the two specifications following the rules that we've set up right like our focus should be in interoperability. And that's not the details of how to implement that the aggregation pieces because that's completely dependent, and I think that those aggregates need to be free to make decisions around. Like, maybe they do want to change the epoch or maybe they don't expose the epoch they got from downstream, and they save it in some sort of cash and rewrite it. So they could do paging and a bunch of other fancy stuff as an internal detail, but and then authorization basically. Yeah, absolutely. So I'm, like, I'm here to stop. I don't know if there is already a project that does that. But I think it will help me at least get really into the full grid work. If I initiate some kind of project like that. But I mean if the work already exists somewhere. I should not do it, I guess. But what language is your main language. Like, I read on care. I'm not saying that go is my favorite. If I had to learn go and do it in good and I can do lots of type script but I'm open. I think we need a type script version so so the point of the interrupt demo that's happening in November is that we would like to be able to run through this simple flow, and then maybe run through more complex thing with several representations that read from the spec that implemented with the spec set to validate that the spec is actually feasible and doable and implemented implementable in several languages. And my, my goal, like, at least when I thought this week was like, even though I would like to have just a small react or what are you why framework you prefer. But like a small UI that is basically for human to really see those endpoints. It will be nicer than just API is. And that's basically the beginning like the way I see it. But I don't know if I'm hijacking this meeting. If that's okay, you can tell me is like, I would love to have a UI where basically I say okay, I have a new service like service that I know that is on that URL just it is the discovery point and just import all the services. And then I have a third one that is whatever language it is I don't really care because then I'm just going to use by the discovery API. And then they, they subscribe automatically and then you can just come and subscribe to this gateway that will basically get all the information from the other services and aggregate like an act as an aggregate. I think this will be super concrete to me, and I will really understand what we are trying to do. While in the last month, I was a bit more confused. But again, it's maybe just like, I can take the blame with that. We're headed, but we need to validate the spec first. So, the goal is that by before the end of the year, we have an RC pitched, and then folks can start working on actual like implementations of this thing that do real things. Okay, so maybe I can start in advance and you say it's fun November. The demo you want to show. And then Doug is like November two. That's the date. Yeah, November two. It's coming up fast. Yes. Okay. Break this down into let's say some tasks so that we can start coding on this. You code your own version, we're going to do an interop. The task is to you independently go and read the spec, implement what it says and make sure it makes sense. One thing it does is makes you read the text and see if it's all correct. And the other one is make you implement it to make sure it's like technically feasible. And in other interrupts, we did have different people signed up to do different parts of the overall demo like they, that way everybody didn't have to implement everything. In this particular case, though, I do think it'd be useful if everybody did implement everything meaning they put a discovery and point the interrupt they provided a service that you can subscribe to they everybody wrote their own client. And that way we can test again, you know, and and by a matrix. I think it's good. Right. So yeah, my vision there is there is like the basic discovery API that I was trying to put in the SDK just because when you do a simple service. I think you have value to be able to express like a basic discovery service. And then for the whole interrupt, I think it has value to get the more complex aggregator that they have in mind. I'll try. We'll see. But I try to implement something for next week. Okay, it's got just to go back since you since you're going to revamp this section here. I think I understand the mental model that you did that you described in terms of the upstream downstream stuff and like and stuff like that. One thing I'd like to you consider not necessarily for this call but as you write this up is to explain how you see it working. When you have another party involved, who's doing the gets against both the upstream and the downstream and then the same service comes from both guys. Right. And, and the epoch values don't match or something like that. And, you know, what if one or both of those of those upstreams to that third party guy, update it right which one does the guy use that kind of stuff. Right. I'd like to understand how you see all that playing out. That's exactly why I was saying that the epoch needs to basically be immutable as it goes becomes aggregated down to different services. I would expect that. So, it's so hard. Oh, man, isn't there like a, I can draw on your screen or something. I don't know. You can you just go to the view options and click on annotate, and then I'll stop to put a white screen. You require annotate. Oh, here we go. Okay. Now I'm worried. Gosh, go on a blank screen that would be. Oh my goodness. All right, so let's say we have this situation we just talked about. Hold on, hold on. You know, you got to give me a break. I'm using a trackpad and I'm trying to. I want to get rid of the text. So there you go. It's a blank. So to make it clear that the arrow of direction is where the request is coming from. So, so see here is the, maybe we'll call it X because that's a little easier to draw. Oh my goodness. So X is the final consumer. It's making a aggregate request to A and B because it has a bunch of other users that are going to aggregate from it, or, or this describe ask for subscriptions or whatever right. And it sees there's there's a food. Oh my goodness. Oh, hold on. I have a mouth. This is going to be great. Yeah. Okay, we got a, we got a foo here. And it's is one and a food down here with an epoch of two. So when, when X sees a subscription less and sees the epoch of one, it says, okay, cool. I'll store that and then it goes and calls B and says, okay, oh, you also have a foo and your epoch is to that's more better. I'm going to save that one. And I'm going to drop what a gave me. So now I have everything that be had. I have everything that a gave be, but be could have filtered some of things from a outright so maybe, maybe a provides foo one foo two foo three but be is only aggregating foo one. But now X has all of these catalog, all of the food catalog, but the updated version because be doesn't. Oh, sorry, this goes the other way. B is making a request to a product that is out of date, and X is now more up to date than be, but that's okay because now we know how to reconcile the, what the source of truth from a is around its source, its service foods. And we compare that to be service, but it breaks down if be rewrites the epoch. Right, and that right because you a couple of minutes ago you said something that you did not repeat and I was waiting for you to repeat it which was be is not allowed to touch the epoch that he got from me. Well, it, I think it can make that choice right so let's say, I say, my service X is actually firewalled and I don't. I'm not working as intended if anything reaches around out of this little safety box. I'm going to rewrite inside of the aggregate X, I'm going to rewrite every epoch and subscription API because I am the proxy. And I think that's okay too. It works only if you understand that X is going to be the proxy for a bunch of other things outside of the bounds of the, the subscription contract, but that's an implementation detail of X, and it's environment that it exists in, because it doesn't want all the X ones and X, X twos to reach outside of the cluster and talk to be directly. This is a bad bad. Well yeah well that's what I was going to say is yes as long as you guarantee that that no one ever talks to X and a and B at the same time. Sure you can do that kind of stuff, but I'm worried about the original case where he does talk to multiple people. Right, well. I think that's not something we can control. Yeah, we just need to specify that I just need to write it down and don't have to solve it on this call here but those are the kind of things that I worry about because I'm not sure you can always guarantee that X is the end of the chain, because B may have thought he was the end of the chain and he's wrong. There's an arrow. This thing. It's funny. Okay. Anyway, like I said you don't solve it now just something to think about writing down as you start to fill out this section here. Yeah, so this is kind of why I think that the whole management API probably needs to get pulled from the spec, because it complicates this situation and makes us have to figure it out. And I think that that the push based management API probably should be an implementation detail of a particular implementation, instead of specified by the cloud event spec. I don't want to see how it plays out. But I think I think, I think we need to see something written down before, as an alternative, before we start ripping stuff out. Yeah, okay, let's. So, okay, let's pause on trying to delete all of Doug's work. You can make me implement all your crazy crud. No, no, no, no, that notice notice the stuff I wrote up here does not do anything with the crud. I purposely did not even touch that because I agree with you I that stuff very likely is going to get pulled and I have no problem with pulling it I just want to make sure we have an understanding of how that synchronization that you just drew on the board there is going to play out even if it's all done through gets I'm okay with that I just want to understand it. Alright, so I'll draw one more thing. Hold on the revamp idea. You got, you got a, and you've got B, and you got C, and you got D, and you have the demo x right, and I think it'd be really interesting if this goes and tries to go and ask for and subscribe to things from all of these consumers, but these things also aggregate. And, you know, watch me draw this for like an hour, but this becomes very complicated right. It doesn't subscribe for me. So you get the, the, the complicated hub and spoke kind of looks like one of the machine learning models. Yeah. So instead of instead of the simple case of you have to have a coordinated ring where it, the data flows like this, and it ends up you always end up in these little eddies where, you know, the, the, and then if you add another one and so it's connected like this. You're talking to each other. And you, and by happenstance you can talk to one and get all of the aggregates. I don't know how real this, but so I doubt this is a real scenario. I see real scenarios looking more like this, like a tree. The reason I'm concerned about the little eddies is because I think once the tree gets big enough, you start to do things like this. And then that makes me nervous, because that if you flatten this little connection, that's a ring. And then the epoch becomes very important. Yeah, well your entire premise that that if you, if you get an epoch from somebody upstream, you're not allowed to touch it that may help solve that problem may. It may. I think you're not supposed to touch it. And I think you're also not so. You should allow the case of complete proxy where it rewrites all the data and the subscription and points and everything else because it wants to be the delegate. Maybe. Yeah. Alright, I need your hands up. I'm just a bit confused. It's like a B and C, for example, were they the producers in this case, and it becomes a consumer or everybody is a producer and everybody is a consumer. I mean what sort of model are we talking about so that I live in a middleware world where there's, there's a cluster and there's maybe some functions going on and they produce events and they also consume events and they subscribe to events. But that may be just one in a series of clusters that are connected through some sort of means and the discovery and subscription APIs are what I'm trying to get those clusters to link together so that they can pull down what's available in the universe of events to be subscribing to and then aggregate up subscriptions that apply to that particular endpoint. That's a fair thing to tackle down at least in terms of distributed system for sure. But where I got confused is like how can how how does it. I mean, how does the collision happen. So, in what scenario is it like the epochs for example are going to be mutated by because they have to work on the same object right if they are trying to mutate it and every piece in the A, B or C individually they have their own discovery specific their own discovery endpoint right so that means they have their own catalog of events in this case. Right, the epoch came about because my first prototype of this I implemented a ring and I implemented a very simple like I think 10 seconds sync time and it very quickly showed that based on timing I could get a bubble of incorrect data flowing through each node where it goes and it it propagates the wrong data down and then aggregates up to the correct data and replaces the wrong data, but you have this little bubble of incorrect data being synchronized between all the clients. And it's replaced by what's behind it, because there's no way to compare it and so that's where that's where you talking from your hands up. Yeah, it's just, if I may draw go for it. I open the world for everyone. Yeah, it's just that's the first time. So I click on annotate and then I can draw and you will see. Wow, nice. Yeah, my vision was, I'm not sure I'm going to do better than that there. If I have a then you'll have B and all that. My, my GW, like my gateway, the way I see it is more like I managed security for an XO so I can probably really focus on security is like, I would ask them to subscribe to all of those. And then my internal employee will only subscribe to this gateway. And if be needs to see a basically the way I will see it is I will ask be to subscribe to my gateway, because I probably need to filter some of the a event, because I don't want to be like let's go to GitHub and that side and I don't know my ideas and the B or my CI on the side. A will start sending me all kind of events. And I, I don't want be to see some private events from GitHub. And this way I will have better control if it goes through a gateway so then I won't have those kind of token and, and that's why I was talking about like kind of gateways or aggregators is just because if I have lots of connection between like a and B and C and anything like that. The way to manage permission in between might become harder for me, if maybe I'm wrong. That's what I have in my brain currently. Any comments on that. Yeah, I think so I think the situation that is implementation specific is if you have see down here, and it's talking to gateway and it talks to be. I think in this in the environment. This is incorrect, right like, yeah, correct. Yeah, like, I will go to the team that manage see say okay, like you don't don't go to be directly because like it's not manageable for me. In a good way, like because then I have too many flows that goes everywhere and to explain to like our compliance officer it's going to be hard. Yeah, I think you can solve that with off here. And firewalling. Yeah, he's not possible. Yeah. Yeah and that means then the concrete is more using that. So that's why I really want the gateway product. And because without it, I don't see how we'll do a good implementation in my company. Yeah, absolutely. And I think that's, that's why the gateway needs to be able to write epochs and things, but yeah and even like filtering capabilities maybe like with some Jason rules or something to basically as this message can go through or not and yeah. Class your hands up. Yes, so to remarks. First, I think you might want to have a closer look at DNS, because they are doing this and something more. And I wonder if it's really a good idea to do this via the same API as the discovery itself, because you will also have to deal with different kinds of authorization models for those gateways and for consumers, I would suppose at least. Yeah, that's right. That's right. So for me, it's easier because she will be like, let's say it's an internal team, then they will use our internal authorization like systems and things like that while on GitHub. I have like my application that is like on the organization, which I don't want to see to be aware of that like we need authorization and that's why like earlier when we talk about authorization. Kind of eluding the subject. I think it's still really important because coming from security like we don't live in an open world. We don't like we need to have a way to close it down so maybe we should. The gateway again needs some kind of token then to access A and B so correct. Back to DNS in DNS you have servers that are authoritative for certain zones and so this fully distributed approach I think is really hard. I mean, distributed systems that you always reach the point when you have some central component. So that's why I wonder if this fully distributed approach what Scott was mentioning before is really feasible. Another thing. I wonder if also something like a document format for exchanging events between discovery and points might be a solution so that you don't use the usual discovery API but something like a document format where you can have a well defined bundle of events you transfer to another discovery endpoint. Elaborate a little what why do you think that it's a bit like the zone transfer you might have in DNS or. Yeah, I'm just I'm just know what I'm what I got stuck on is what's the difference between an event describing a change versus just doing a get to get that information. Why would an event be different than just the metadata itself. No, it's an event so what what I mean is that a could provide some some documents containing the services or events. It's making this coverable. And then the gateway could then retrieve that document and you don't run into all these authorization issues and yeah, more more in the spirit of using API open API and those standards. For me, doing the get on the API or because at the end, even if you have the definition so for what I understand the document will be kind of the definition so an export. But when you subscribe because the gateway still need to subscribe to then provide the right events and I see, I see the gateway not only from the discovery part, but if you only take the scope of the discovery I think you can do exactly what you said. But I was thinking for me the gateway should also provide because of the authorization more the aggregator of the cloud events, it should not only be the discovery part, it should because I agree if it's just a report then it's just a definition so you could load up the definition almost without speaking to a or B at all. So I could, I could imagine still to have the proxy mode, so to speak for the discovery API. But if you really want to transfer the whole discovery data to make it available somewhere else. I don't think the API is the right way. Yeah, the proxies. I think. Yeah. Okay. Simon your hands up. So I also see the problems with distributed systems which have so many relations between them to sync it. And one approach we are currently evaluating is to make a distinction between aggregators and providers basically of such information. So in that picture a and B could be relatively stupid and just implement expose basically what in a declarative way what events cloud events they expose. And then we might have an aggregator like the gateway in here, which basically fetches those information from all sources it knows about. And then this is the central entry point. So there are more aggregators than one, but you won't have that many. So it's more manageable. Okay, if I mean, sir, if you're right. Yeah, that's, but that's why I if you look on the, the way I first implemented discovery was exactly that the SDK had like a simple, not intelligent discovery system to just publish what he was emitting as cloud events. And then my second thought is, I need to have that gateway because like I need something that is way more clever but that's. And then as a developer of a it's easy because within a few lines of code you just have your discovery service running. So the gateway I have my, my team who will basically connect all those small services, and then we can just publish to the whole company which sits on the seaside, all the events that they can consume. Yeah, that was also we had a very similar motivation behind that also because we had a lot of we have a lot of systems which would provide events. So we need to keep the effort to provide discovery as low as possible, and then just add all the extra functionality in a single place or maybe two places but a very limited amount of places. Okay. Yeah, so there's so many things going on. And so I apologize for not keeping up with the discovery stuff in general, but there's, there's, there's like, so let me go back to this epoch issue. Right. If you're, if you're going to allow rewriting, you now have identity problems. Right. So that, that's, you know, I think what Scott, he had to leave but the, you know, the issue of creating a bubble behind the gateway is, if somebody wants to create a bubble, that's up to them, but then you have all these restrictions. Right. You also have all sorts of security problems when you're now basically inducing a man in the middle. Right. So it's not just for authentication and authorization. It's, it's integrity, it's trust, it's, it's all these additional features. So it's not just the issue of, well, are we allowing people or not, or whatever. Or however you want to say it in, in specification speak, but, like, what, what's the identity, like, are we changing the identity of events coming from a and B in the gateway, such that the gateway is the authoritative truth. Right. Or are we pretending the gateway doesn't exist. But if you're adding functionality, and you're basically changing the semantics of things, that's fundamentally a different thing. So you, like, so there, it becomes this is part of what induces all of this messiness that people are talking about. And what you've got is you've got multiple dimensions that are that are now in conflict that you don't have any ability to tease apart, because, like, all bets are off. Right. Either you say to the, you know, see is talking to the gateway, and it only knows about the gateway. And so the catalog this aggregated catalog coming from the gateway is the source of truth. It knows about the gateway as changing the reference frame of the universe, relative to its consumers, right so see in this case. Right. Yeah. Yes, but I would argue that the aggregator and the gateway can be two different concepts. I totally agree. That's what I'm, that's what I'm getting to, right. You have, we have to start teasing this apart. And in the fundamental building block is the notion of, well, what is identity. And that goes back to, I forget to mention DNS right the notion of authoritative versus recursive resolvers. There's the right we're adding complexity, and we're not adding the capability or at least so far. What we're talking about is not adding the capability and the expectation management around. Okay, well, how do I resolve these different complexities that we've, we've allowed for. We're like, because there is an intermediate that is defined on cloud events, so you can just like be the one passing the message. I will consider that in that case, like, I'm not a big fan of rewriting. But if you rewrite, it's, it's not really a rewrite, then you create a new event based on the previous event. But for me, it should not be a modification. So basically for C is either I'll provide them like com.github event, which is basically what they will find from GitHub documentation, and then I don't do anything. Or, like, my company is Nuxio, if it's Nuxio, then it's going to be nuxio.github, and then it's a completely different event that might be a like of the GitHub or it's something completely different. That's my own decision to transform it. If I transform it, then the gateway becomes like the source of the event because then that means it create new type of events that is specific to my company. So this, but I'm really not a big fan of like rewriting the message without, because as you said, even for authentic, like, integrity, if you start signing the message, it's not going to work anyway. So if you look at the work these days in, you know, whatever I hit the term, but zero trust, right, networking, it's just like more and more problems that were added. So my concern is that if we're going to, you know, open up these kinds of things like epoch rewriting and those kinds of things from the standard perspective we can take a totally neutral perspective and say hey if you do that then that's up to you we don't we we don't guarantee anything, but if we take that loose of position, then now we're, we're basically opening the floodgates to interrupt problems by not specifying enough about, well, what should be done what could be done. What's, you know, these best practices of, you know, if the identity is ultimately GitHub, then whatever your gateway is is is really a proxy. So then are we specifying enough, enough grip in the system to pass through credentials and whatever we need to do so that it's it's actually a secure or secure a bull proxy versus a new source of truth that's doing whatever it wants to do. I like, I like the fact you focused on identity, because I that's an interesting aspect that I was kind of wondering about is, if we're going to allow one of these nodes like the gateway to in essence, not just be a pass through for the epoch but it's going to allow itself to set the epoch value then, if I understand you correctly, you're almost implying that if he's going to take ownership of the epoch value, then he needs to almost set a new identity, in other words, a new GUID that surface. And I like that approach because that that could solve a lot of the problems. Right. And so if you, yeah, so yeah, if you start mucking with the epoch, then you now become the source of truth this guy. So yeah, give it a new identity. And then it's no longer the same thing is where you got this information from they're not two separate resources or either you proxy or you create your own based on something like another source of truth. If you want, but it's a new one. And if you're a proxy, then you're not allowed to touch the epoch. Yeah. Yeah, you're a proxy, you're a proxy. Because that kind of model I can understand around my head around very simply, it may not be satisfied every single use case, but at least it's something I can wrap my head around. And then that's the security building right that gives you a better building block for the, you know, in the end authentication and security like, oh, hey, I have to authenticate to the proxy for it to give me a channel outward. Yeah, yeah, I'm authenticating to GitHub. That's a pass through a proxy versus a rewriting new source of truth aggregator that I just aggregate to it and I only see its catalog and I don't even know about GitHub. Like, because my use case will be like my engineers will be on C. I don't want them to even have to worry about how we authenticate with GitHub if I want to change that and basically the connection between a and the gateway will be managed by the, I would say the IT team. And then as an engineer I see you just connect to the gateway with a normal authentication like what they are used to do. And they don't have to manage that because, like, the bigger the company the more system so it goes to a to ZZ. Well, I mean you have all the politics, right all the politics political problems, right. Yeah, you know big customers demanding punch throughs one way or the other and all that kind of stuff so there's there's plenty of external nightmares that we can add on top but if we don't give them the right of building blocks. It's, it can't possibly work in any sort of secure manner. Right, and certainly, you know, at a Reba part of SAP, we ran into this all the time, like literally huge customers trying to say, Oh, we need access to your back and database directly. I know that when you have when you have a Saudi prince calling, you know, the president of the company. Shit happens. Yeah. Okay, so this has been a wonderful discussion. It is a slight tangent from the interop. However, it is all good. If somebody. Why am I still in this darn mode. If somebody wants to write up the stuff we talked about here as a proposal for the spec itself. I would love to see that, but I know where everybody's busy with other stuff and we're focusing on the interop, which is not going to touch. I think this stuff anyway except for maybe Scott's. If you want, I think I draw this one. So if you want me to put it on paper, like it was really good to have this conversation because I was not sure if I was right or wrong to be honest with the group. It seemed that this idea is not completely stupid, which No, if you want to, if you want to write down the idea, whether it's part of the spec or just as a separate doc that people can iterate on and brainstorm on and then eventually it leads into something for the spec I think that'd be great. There's also this discovery primer. True use cases and scenarios perhaps it's also something for that. Yeah, and my goal is so for me, a and b was supposed to be the small PR I did in the SDK, like for discovery service, but the gateway is clearly another open source project that I can start on my own repository for now. But I think it will help. I'm not explaining that so I can work on it and definitely for if we do an interop, I think it would be nice to have at least some draft on that. Okay. Anything else we need to talk about I think we have a plan. How do I get rid of that annotations. Can I actually clear it. People drawn. I have power. Okay. I have one favor to ask, of course, I mean the scenario what we are talking about in terms of interop is a very, very technical scenario, we probably got to add some sort of story behind that and I think you're the best person for that. You're talking about this stuff down here right now this one's easy right. Yeah, I mean, these are like very easy to implement but we got to tell like a pitch behind that. That's why I mean at least when we're going to give a demo about this right. Yes, yes, we have to yes we have to present it in a real in a real world scenario not just hey you can take and talk to be it isn't that wonderful yes. Yeah, and that's, I think you're the best person for that right now. I appreciate your sign me up for work. I appreciate that. We'll get there eventually yes. I believe we need to get people to access our coding first that's the hard part. So, I agree, we'll go get there. Okay. All right we get people starting to take off now. All right anything else last last chance. All right, in that case we are finally done. All right, thank you everybody will talk again next week. Okay, bye.