So I know in the past we talked about doing some sort of SDK demo kind of a thing at KubeCon. To be honest, given the workload or given the activity I've seen, I'm inclined to think that that probably is not going to happen. Now, that doesn't mean that we couldn't showcase some of the SDKs. For example, Scott, I know you guys have done a lot of great work on the Go SDK. So we could showcase that someplace in one of the presentations that we wanted to. But in terms of some sort of global SDK interop thing that we once talked about, I'm not sure it's going to happen just from people's workloads, but I wanted to get your guys' take on it. Yeah, I think that's probably right. I think we'll get there. Yeah, I just don't think it's going to happen this time. Yeah, maybe KubeCon ENA. Yeah. Although my plan is to show the writing ace, a cloud event consumer producer using the Go SDK for the intro. Yeah, and I think that makes perfect sense. But it's not necessarily really about the SDK. It's more about like what it looks like to produce events. I'm assuming though you will highlight about how the SDK made their life easier. Yeah, yeah. For sure. Yeah. Okay. Cool. I think the point about showing the SDK is that you try to decouple the idea of consuming the transport away and instead focus on the payload. Yep. Oh, speaking of payload, just a question for you. As I mentioned to you a while ago, I think someone I know was using it because they were getting base 64 or all the data was base 64 encoded. As opposed to just raw JSON. Has that been fixed? That was, that was a bug in the K native SDK. Oh, okay. Never mind that. I don't think it, I don't think mine does that. Okay. Excellent. Cool. And K native now does use your, the, the go, the SDK from here. Right. Yeah. Yeah. So in 05, we, it'll, it'll all be the, this SDK. I actually found an interesting bug that I introduced. Adding headers and stuff, but there's a new release now that fixes that. Cool. Oh, speaking of headers, we still. Really need to figure out the. Extra quotes thing. Yeah. I'm just looking at the agenda here. That's not on the agenda for today's call, but we should probably definitely talk about that. I know Clemens, you had an opinion on that, but your opinion was to keep the quotes. Which is. Keep the quotes. And that upset some people. I think we should also add extra time zones. Just for you. Like a Tuesday time zone. We'll just shift it back by like 35. Are you trying to be funny? Yes. I'm just, I'm just, so the opinion is just based on us allowing maps in. As types in. In attributes. And if we do so, then we need to be able to go and encode the full range of Jason in that field. And then. You know, a quarter straight. Right, right. So that's, I'm not arguing against that. I'm saying for the known types that are core to the SDK, the things that are always going to be sent over the wire. I think they should be special cased. Because we understand their types. And those are your extensions and unknown. Yes. But then, then, then now you're in. Tractors territory when you have a unknown type.  And all of a sudden that's incompatible because prior to that, it had to be cured from Jason role. And now it becomes to the elite circle of things that have Yeah, I was going to suggest something slightly different, which is for a well-known set of types like String, URI, they just don't get quoted. But for other types, they can follow the JSON encoding or whatever you want to call it. Yeah, but now you get into the funny, you know, it gets it's a weird, then you kind of have weird edge cases where the customer is now choosing just to put numbers in there and yeah, yeah. The trouble is that the current spec on the wire for binary mode HTTP looks really strange. What do you mean? It has a bunch of double quotes in it. It looks really strange. Like to compose that, you have to do a bunch of weird stuff. So can I, let me interject here just for a sec. I definitely won't have this discussion, however. Let's make sure we cover any SDK topics first. Are there any? That's what I was going to ask. Is there anything related to SDK since that is the point of this call that people want to talk about? Yeah, I don't have much. I don't have anything else. Maybe, hey, Clemens, do you want to make our SDKs talk to each other? Yes, I would if you just speak to the spec, it's all good. Oh my gosh. So hold on a sec here. That's the whole point of that document. But specs are allowed to have typos and bad ideas. So hold on. Wait a minute. As long as they're there. Wait a minute. Wait a minute. Okay. Before we get back to this, Mark, you said something interesting there. You said you don't have much. Does that mean you don't have any? Does that say much? Yeah. No, I'm good. I'm good. Okay. Okay. Hind, is there anything you'd like to bring up? Maybe Hind, step the way for a sec. Okay. Well, let's go back to the attribute. So regardless of the correctness of the quotes, I would like an official from on high ruling because I can change the SDK to be compliant and that's no problem. Or I can leave it the way it's currently doing and it'll only talk with my SDK and people that didn't read the spec as well as the C-sharp SDK did. So Scott, I have a really hard time. Like I've looked at this and I've thought about this for a while and it's kind of hard to prove because I have nothing written down about it about the thinking, but as it is, if you decide to not change anything, I want to see the rule, like write down the rule, write down what you think works because I don't find a future-proof way to make this work and still allow the rest of the type system in those fields. But it works because of versioning, like as things get promoted into versions, then they can- Yeah, but I want to have an- I want to have an- I want to have a normative explanation of the exception that you want the formulae, like I want to see it writing. So Clemens, I think I can come up with a rule, but I want to make sure I understand what you said earlier before I actually put out a proposal, which is when I said we know how to serialize the types that we know about, like strings don't have code and stuff like that. You said there are some edge cases that cause concerns in particular that someone can just put a number there. Explain to me why that's a problem, because even if they put just a number, if we define it as string, it gets read as a string. All the- so the reason for that is that it's effective for all extensions. Anything that's data that's just being added as extensions is defined well-known or unknown to the envelope. Anything that's there. We basically rely on type inference, or we rely on, you know, type information in the the- sorry, for AKP friends, we rely on the AKP type system because that's there, right? And there you say this is a string, and this is a map, and this is an ins, and blah, blah, blah. So that has that. For HTTP, since HTTP, the header is a string, you rely then necessarily on type inference of the encoding we've chosen to use, and that's JSON. And so for- to figure out that something is a string for an unknown attribute, you'll have to rely on, you know, a string being coded because otherwise you can't identify the string where at least you can't tell it apart from a string that contains only numbers, and you probably don't- you don't necessarily know what to do with curly braces or with square brackets, et cetera. So you have to rely on- you have to rely on type inference. If the case happens, if then the case happens that a unknown type becomes promoted to a well-known extension or becomes even more so, becomes a part of the core spec, then all of a sudden the encoding changes. And that's a little strange. But Clemens though, when an extension gets defined or when an extension is used, there are two options in front of them, in front of people, right? The extension has been well-defined so you know exactly what type it is. Yes. So there's no ambiguity there. Well, there is because you can choose to completely ignore an extension. No, no, well, but then, well, that gets into the second case though, which is even if it's defined, someone may not know about the specification and therefore it's unknown and what does someone do with it when they receive it, right? Now, in those particular cases though, I would say that that almost falls into the category of is an implementation detail, meaning the receiver is going to decide how to take this particular string in essence and decide how they're going to store it. It may look like a number, but they could choose to store it as a string and pass that on to their function or their code, the application, in whatever format they want. That doesn't affect our specification. That doesn't work because if two receivers that are trying to consume a binary HTTP encoding attempt to consume the same string, they need to use the same rules. And so they do need type inference. Now that I think about it a little more, I think the rule that could be future proof is that for everything that's in the core envelope, they don't need quotes because they have strict types defined by the specification. For every extension and unknown or unknown, they use the quoted JSON mentality. Yeah, but now you've bolted down the extent of the core spec for eternity. Well, I'm sorry, bolted down. So if you use that rule, then an extension property, let's say the thing we've discussed with the partition key, right? If that's something that becomes so important that we think it needs to become part of the core envelope, then it will be quoted as an extension. But then as soon as it marches into the core envelope, it will be no longer quoted, which means that all code that is using it will now have to be effectively rewritten, adapted for it to be not encoded with quotes. I'd like to understand what you said earlier, though, Scott, when you said two different receivers are going to have to think about my proposal that wasn't going to work. Can you elaborate again or say it again? I was saying the two different consumers need to understand type inference as things come in. But don't they only need to understand how this particular attribute is going to be handed to them from their SDK? No, no, no. It's independent of SDK. Okay, so let's say two SDKs are going to consume the same event and invoke some function. The inner representation of that, the envelope, the context data, and the payload may be exactly the same, right? Yeah, but my point is anybody who is actually going to use that attribute has to know two different things. One is how the attribute is defined, right? It may look like a number, but it's actually a string, that kind of stuff. And that's part of the specification of that attribute. And they just have to know that by understanding it. Otherwise, they can't really use that data for anything meaningful anyway. And two, they have to understand how the SDK is going to hand it to them. And they may be handing something that is technically per the spec of the extension a number, but the SDK may hand it to them as a string because SDK doesn't know about it. I think the difference between Clemens and I's perspective and Doug's perspective is that Clemens and I are thinking about middleware and not the end consumer, and Doug is thinking about the end consumer. Right, so Doug, in that case, so I have a case, I don't know what's making that noise. There are some Microsoft software I really want to kill. So the, here, the case I'm thinking about is Event Grid, where the incoming request is a binary HTTP request. And then there is a route to a service plus queue, which then runs over AQP. And for that, I need to be able to take the properties that were set and map them effectively into AQP properties which are appropriately typed, and then flow them over to the other side. Where there may be, there may be actually be on that route, there may be message selector rules, which are dependent on what that type is. So I need type inference basically to keep the types right as they flow from HTTP into AQP. I can't ignore that and simply say, well, you just deal with it as a string. I agree that it might be okay with that, sorry, for the core properties. But as soon as it gets to extensions, then the middleware will, generally the middleware will not know about extensions except the ones that it cares about handling. And then, and so for that we definitely need inference. And then for me the question, for me then the compatibility question is, is one of, when I go and promote something that is currently in extension into the core spec, that changes everything. And so, and then that becomes inconsistent, for me that's just a bug source. Hines, were you going to say something? No, I'm just wondering that on the selectors aren't most messaging protocols. Selectors are against the headers and the headers are usually, and there might be exception where there are always string based name value pairs, so it'll always be a string, won't it? No, in JMS they're typed and they're, so JMS, JMS where brokers need to know the data types and MQP is completely as a full type system. JMS headers are all Java strings, there is no typing in JMS headers. It's implicit, they have math functions, some brokers do. Oh yes, but it's a string that's passed to you. Yeah, but then you're effectively inferring that from function, but in MQP, in MQP, so my perspective on this is effectively the MQP mapping of JMS. In MQP, the underlying type system of MQP allows for properties to be typed. They can't be complex types, but they can be any of the valid MQP types. Go ahead. No, so they're just the primitive types, that's it? Yeah, so it can be numbers and you can even have dates and you have constraints, but that's permitted. What's constrained in MQP is that the property names need to be symbols, but the rest, the value space is unconstrained. You can't have lists, you can't have maps, but they can be any of the other types, so that is type safe. Does the cloud of inspect actually have to understand the types? Or can the cloud of inspect treat everything as a string? We have a few things that are not just strings, right? Well, we don't have very many, I know that. We have an integer. What's it used for though? We have time stamp. Which is basically a string. Yes, everything is just a string. Well, that's how I'm kind of wondering, can we punk on this? Because HTTP doesn't have this problem, right? Everything's basically a string to them without actually saying it's a string, it's just a bunch of characters. I'm wondering whether at the cloud event level, we actually need to worry about this. Or we just say, nope, everything's a string and if you understand the types, then fine, you can convert it, but that's outside the scope of the spec because that's outside of cloud events processing. Yeah, I've done a lot of work to take like, for example, dates and turn them into strings because Go will serialize out a full date structure if you're not careful. Yeah, we have strings. So what we started with, so what we started with in the type system is that the integer, the integer was the thing that started that started throwing out a string, meaning that a little bit more complicated than it needed to be. The goal was basically with the type system to distinguish between strings. And then, which was most of what we had, and timestamp as a special case of that, because that is a string expression. It's just a specially formatted string expression. So timestamp is effectively derived from string. And then we only, we effectively had the binary as a special case because that might be expressed as string, but then in the cases where you have the binary encodings, that is effectively bit by bit being put into the binary body. And then the rest of the constructs like the map is for complex types. And then any is either of the two. And I think with the integer, we broke into jail and actually having to think about different encodings for these primitive types. Yeah, but if you look at the current types that we define our spec, not look at the extensions, but everything in our core spec is basically a string. Yeah, that's, yes, it's a string or is a derivative of the string. That's right. We could basically say, yep, we're going to kill the integer again. For the data, the fact that the reason why we have, why we have binary is really to just accommodate binary in data in the any type. Like binary is never used directly. But just for attributes per se, which we're now debating, we're not talking about data, we're just talking about the attributes. For those string and string rise types would be sufficient. And so we could go and pump, basically pump on that problem. If we get rid of the, get rid of the integer. Yeah, this is the only use of integer I could find. And that's in sampling extension. Yes, yeah, we introduced it specifically in that case. But it seems to me if we, if we change the spec to be just everything's a string period, we don't have this problem anymore. You could, and you could subset string like timestamp is that it has to be in a particular format, but ultimately it is a string therefore we don't have to do JSON encoding on it. Well, even for that one for that extension you were just showing. It's still encoded as a string and header. Yes. Are you saying you want quotes from it? I'm saying we say it's encoded as a string that should be parsed as an integer. Yeah, that's fine. So, but yeah, then it solves the problem. The issue that remains them though is that if you put a map into an attribute. Then we have, I think we have a few extensions, or do we? Then, then, then the question is, can we can we represent that accurately? Like, can we encode that because the map is effectively like we need, we would have to go this thing is between the strain and a map. If we say, okay, maps are legal for attributes, then that gets gets us out of that out of that as well. Well, what if we did this? What if we said if you're going to define an extension that is a different type and map is a good example, then you need to define the proper serialization for that particular attribute as long as it can be serialized as a string in the end. And if that means for this particular extension you want to be serialized in JSON format, then that's the rule for that particular attribute. Yeah, then everything has two representations. There's the structured way and then there's the binary way. What do you mean by binary way? Oh, I'll always say what you mean, binary. It's something we can, like I'm not opposed to that. So I'm just, I just, we just need clarity, I think. Yes. And if we limit the choices, that's fine. So as it stands, I think we need type inference. Because we need to distinguish between principally between strings and integers and maps. And if we say we're not allowing maps, but like if you want, if you need five fields in your extension, well, bring five fields, don't bring a map. And then so that's a thing that's that that's the thing we can say. And then we can strike the integer and say, well, if you need to have a number, but ultimately the only way you can go and encode that is straight. And then in that case, then it's easy because then everything is a string or is at least something that is encoded. It encoded as a string that interpreted in a certain way, like in timestamp. And we're okay. Yeah, I would let the quotes go. I would much rather head down that path. I think it's a much easier model. Well, and then that's, then let's, let's go do that. Yeah. I have cash over to the, to the customer call and I will hopefully be able to rejoin the call at some point. Okay. So much to talk. Okay. You want me to try to, to draft that proposal. Sir, if you would, that would be fantastic. Okay, that sounds great. That sounds perfect. Thank you guys very much. Non SDK discussion, but very important discussion. Very important discussion. Okay. Okay. All right. So people trying to, but I will try. Yep. Okay. Scott, you're still there. You're still there. Eric, you're there. Good morning. Good morning. All right. I should just mention I couldn't get off mute there when you asked me if I had any other issues. The only issue I had is that I did offer to referee a discussion out in the parking lot. If necessary. Are we going to get into a fist fight? Is that what this is about? Well, it started like it to me. I thought it actually went really, really well. Good. Hey, I don't have any spare tables. So it wouldn't be a very fair fight. Hold on. I'm sorry. I'm sorry. I got distracted. Somebody's paying me. What? Can you make an action item for me to stop volunteering for things? Can do. Yes. I said, maybe one thing we can't write down. Good morning, Adam. I assume you're in the West Coast. Yeah. I just just making conversation. I assume you're on the West Coast, right? Yeah, about 50 feet from Scott right now. Oh, in that case, I apologize. Okay. Ginger, you there. Good morning. Fabio, are you there? Yes, I'm here. Hello. John M. Is that John Mitchell? Oh, no microphone yet. We'll get back to him. Hello. Yes, Robert. This year. Hello. Is that Vladimir? That's right. Good morning. Good morning. Is that John Mitchell on the phone? That is me. Good morning. Good morning. Are you also in the Zoom under John M? Yes. Okay. That's weird. You come into two different ways. Okay. Oh, it's because I dial in for better connectivity via my phone. Ah, okay. That makes sense. Cool. Thank you. Yep. Christian, are you there? Hello. Hello. Tam, are you there? Good morning. Good morning. Javier. Javier, are you there? Hopefully I'm pronouncing that right. Yeah, thanks. Good morning. This isn't your first time, right? I already have you in the attendee list. Yes. Or is this your first time? Okay. Thanks. I don't think I have you. Hold on a minute. What company are you with? Code it. Code it. Code it as in code. It's like that. Oh. Yeah. Without the E. Oh, interesting. Okay. Cool. Thank you. Thank you. Thank you. Thanks, Sarah. When you get a chance. Let me paste a link to this in the chat. Can you just add your last name? Just so I have that proper attendance list. Yes. Excellent. Thank you. All right. Mr. Curtis. Are you there? Yes, I am. Hello. And Mr. Mark. Are you back? I'm back. Oh, I'm sorry. Go ahead and have you. Okay. Yes. I can spell it is H. U. A. Thank you very much. Uh, Christoph. Are you there? Yes, I am. Hello. Um, Jim, are you there? Yes, fine. Okay. And Jude. Are you there? Yeah. Okay. Rachel. Yeah, I'm here. To Peany.  Whatever. Okay. Hey, I'm here. Hello. And William. Yep. I'm here. Okay. I'm missing somebody. Oh, yes. Oh, that's who it was. Yes. Thank you. And then Justin Johnson. Are you there? Justin, are you able to come off mute? Yeah. Okay. Just say if you're trying to talk, it's really hard. I'll take that as you'd be in there, but it's really bad connection. And Justin just made, oh, we lost him. Oh, he's back. So Justin, I think this may be your first time in. If so, can you do me a favor and, um, add your company affiliation if you want to have one into the gender next to your name. Just for the attendance tracker. I put a link to the document that I'm editing into the chat. If you can see that. All right. Let me do one like look, and then we'll get started. Okay. Okay. Kathy, are you there? Yes. Okay. I think I got everybody else. Oh, Doug, are you there? Like Mallory. Oh, no microphone yet. Let's take it back around with him. All right. Let's go and get started three after the hour. Um, AIs. I don't think there's anything here. Um, As I should mention, we had a discussion during the SDK call, which was right before this one about the header of value issue that I believe Adam opened up a little while ago. Um, I think we had a really good discussion and Scott took the actually had to write up a proposal. So expect to see something there soon. We don't need to go in that now, but just let you guys know we did. I think made some good progress there. So hopefully we'll see how that turns out. Um, community time. Okay. For newer members of the group, this is the time for you to bring up any topics that are not normally on the agenda. So do we have any issues or discussion points people would like to bring up from a community perspective. All right, moving forward then. Uh, SDK call, as I mentioned, we just had one 30 minutes ago. Um, There probably isn't anything worth mentioning there other than, um, I know in the past we talked about potentially having some sort of SDK interrupt type of thing go on at a coupon EU. Given everybody's workload and stuff, we don't actually see that happening. Things could change if people get some free time. But as of right now, we are not planning on doing a interrupt demo for the SDKs that it could kind of you basically just do to people's workloads and stuff. Um, but I think that was the only thing noteworthy to mention from the previous call. Scott, can you think of anything else that might be missing? Uh, no, not so. Okay. There was that one fight that we had. But other than that is fine. Yeah. We don't need to talk about the fight. Um, let's see. Okay. Demo. Do a phone call after this one to continue our discussions on the demo that we're going to be doing for coupon EU. Um, Doug, I see you have a microphone now. Do you want to bring us up to speed on where we are on that just to summarize for everybody? Uh, can you hear me? Yes, we can. Uh, well, I think, uh, what we were trying to do with the, the call after this was to just, um, figure out a good way where, um, the demo could be extensible to accommodate multiple, uh, CE participants. Um, so I think we're still focusing on, um, a simple supply chain within an airport setting, which involves a retail, multiple retailers, multiple carriers, and multiple suppliers and how, um, they can all participate and replenishment of, um, cups that are being used to, um, fulfill drink orders to passengers. Yep. And, um, I apologize as we would have been, as we've been having these phone calls. Um, Doug has been doing a really good job of producing documents to sort of explain the current thought process and ideas we have. We probably should start sharing that with a broader community because I know this Google doc right here doesn't have the very latest. So we'll take the action item after the call, after this one to start making sure that the documents are in a place that everybody can actually see it, even if you can't join the phone calls. But I think Doug did summarize where we are. Uh, does anybody have any questions about the demo work? Okay. Moving forward then. Um, I don't think anything happened relative to the planning, planning for the actual coupon sessions themselves. I didn't realize that, um, I have one question. What is, what do we think of the idea of having a demo that we reuse so we don't have to reinvent the demo for every coupon. So if I remember correctly, I think we were actually kind of hoping to use this airport one to do that as we go forward because I think Doug has talked about being able to extend it in the future. Okay. That's what I think. Yeah. I don't think anything foremost comes from those discussions other than it has come up as part of that. But I think it is a good idea though. Okay. Thanks. Yep. All right. Um, yeah, I don't think there's anything planning wise. I don't even think we've even really gone forward in terms of, uh, uh, starting the presentations yet. The one thing I will mention is that, uh, the CFP for the service practitioner summit is tomorrow. And I did put a proposal for a very generic, you know, what is the service working group type of session for that? Um, and we're going to talk about that offline, I guess, or maybe we could talk about that. If we have time in this call, basically it's just a very high level thing. We just need to figure out if the text is okay. Um, but we can discuss that later. Um, nothing relative to cook on China. So I believe we're into the PR review. Let me just do one quick check here or something. Okay. No new votes to come in. Okay. So into the PR review stuff. Uh, so last week we started a vote on the men's size type of PRs that are out there. And if unless I mistaken, I believe this is the current status of the votes. Is there anybody on the call who thinks I may have entered their vote incorrectly? I believe we had commerce tools, PayPal and Vlad voting for option one. And the other people who voted voted for option two. Does anybody think I got that incorrect? Okay. In that case, I think it's clear. I don't know the numbers, but the two definitely wins over one for that. So this is the one that we're going to go with. Um, I'll, I'll enter in the vote results into the PRs themselves. Um, but is it before we move on though? I think the next steps here is for Clemens to potentially do some wording changes on this one. I think some people had some comments last time, but aside from that, are there any other discussion points people want to bring up related to this? Okay. In that case, just Christoph, thank you very much for helping push this one forward. Um, I know that. It didn't go the way you necessarily wanted, but I do appreciate you guys. You driving this so hard. And I know it painful because it took so long. Uh, sorry. Can I button again? Just to, um, make sure that like if did anyone, does anyone, is anyone not able to do what they need to do? If we go with option two. I still don't quite understand, to be honest. I think we have concerns about end to end reliability. That that's really what the drive of all this was about. So I'm holding comment until I see what the next proposal is. Okay. I'm really sympathetic with that. And I honestly, um, sorry, I'm sick and I shouldn't talk this much, but, um, I think that we have interoperability constraints in either one of these. And so like just speaking for myself, I would have rather had more conversation. Um, and, and I'm really open if someone else wants to keep the conversation going about like how interoper's supposed to work. With either of these constraints. Okay. Sorry for that. Sorry for just dropping that there. I, I used suggesting that we should have a separate statement in the spec around interoperability. And then these become implementation patterns rather than the other way around. Um, okay. I guess for me, I was thinking that like, like I have, I can read the text, right? I can read the text and understand what it means, but then it still seems like there's some unsolved, like there's some outstanding questions for me about how this solve, like it seems like we have an interoperability problem either way, because it's a should instead of a must, like we'll still have problems. And, uh, like if middleware modifies things, like how do we, like how do we make sure that an event can get all the way through that is like, maybe everyone else understands this. And I'm the only one that doesn't understand it, but it's still undefined in my mind. So I'm trying to figure out the best way forward here than Rachel is this. I don't, I don't want it at all block, like going with Clemens proposal. I just want to say like, it seems like the start of a conversation instead of the end of it. Well, that's what I'm trying to figure out is, cause I, uh, I'm not sure that this phone calls the best place to say, have that conversation. Cause I feel like we've kind of gone around in circles for a while. But if people do feel like we may have made the incorrect decision, then maybe we should have a separate discussion. I don't think that, I don't think that it's incorrect. I feel like it's not complete. Like either one of these would have been like, okay, and then this one seems easier to implement to me. But there are a lot of outstanding questions and like there, and we had, we were starting to ask those questions at the end of the call, like in chat, there was like a very lively chat going on. And all of those questions are still outstanding in my mind. So would you be willing to take the action item to set up a call with interested parties who would like to continue this discussion? Um, how about, okay. So I, in general, don't feel like I have a lot of time to like jump on a lot of calls, but maybe a doc that people can like chime in on as like, like at their leisure. Would that be something that people could work with? Does present, I'll give that, but do people want to continue this discussion in an offline fashion? Yeah. The problem for me here is that as far as I am concerned, last time it was me and Kristoff in chat and how that conversation ended. As you said, these, these proposals end up with different constraints. Um, and I don't think there were any questions open bit with me and Kristoff in that matter. It was just, we are looking for the, for different things. Okay. Um, I might have different outstanding questions. How about as a action item? I, uh, tried, how about I write up either like a doc or I think it's, I think a doc's a better idea than like, uh, something in GitHub because like, we probably don't want the artifact of this conversation. Um, to like live in the repo. And try to describe the problems and like a potential solution. As with the idea that it would only be a scare crow, right? That I'm not attached to solution. I just like, I want to be able to describe from end to end how the size, like how the size definition, um, prevents interoperability and how we can solve that problem. Okay. So, uh, so normally I think once we have a vote on something that says behind us, however, because I'm hearing that there may be some people on the call who feel like maybe we ended the discussions prematurely. Let's, let's sort of bend the rules a little here and say, okay, Rachel, go off and create that doc and let's see where that discussion leads. And we won't necessarily rush through merging any PR at this point in time. Sorry. I didn't mean to say don't murder. I think you should totally merge it. I just think like, it opens up a lot of questions for me. Well, yeah, but I also, so let me put it this way. And the reason I'm okay with not merging it is, and this is just my opinion. You know, you guys can say I'm wrong and that's fine. Um, the reason I'm not, I'm inclined not to merge it yet is because I don't want people to necessarily code it up if we decided to go a different direction and I don't get the sense that while it is a very important issue, I don't think it's necessarily a blocker for somebody to implement the spec to test out the rest of it.  It's going to radically change all SDKs kind of stuff. Yeah, for sure. And I, and I think, um, it's a should. And so people can take or leave this one. It's, I guess, like the ultimate get off jail free card here. It is. Yes.  Um, only to say that, uh, maybe I misread the instructions. I thought we've, we weren't voting to merge the PR. We were voting on a, uh, on the manner in which you might measure the size of a payload. Yes, we're in that direction. Yes. Yeah. So I just got a bit nervous when we talked about merging PRs. No, no, no. Yeah. And I just say this earlier. I think Clemens had some work to do to tweak the PR a little and now people can go review it for more stringent, uh, wordsmithing kind of stuff. But my point was, let's say that's all done by next week. Um, I don't want to necessarily try to force a merge in next week of a rewrite of that PR. If Rachel's document has had some good discussions in there, that was my own point. Okay. I didn't want people to have an expectation says, oh, Doug, we took a vote. Why don't we just merge in this thing? You know, kind of stuff. I want to, I want to be a little bit looser with the rules here because, you know, I don't think it is as critical as it has to get solved today kind of stuff. Is that okay with people? Yes. Okay. Okay. So Rachel put together the doc and I assume you'll send out a note or slack or something to let everybody know where the doc is to have the discussions. Yeah, dropping in slack seems great. Okay, cool. Okay. Anything related to these PRs people want to discuss? Okay. Um, next, Scott, hopefully this is a fairly easy one. I apologize if you guys can hear someone blowing their nose behind me. Um, this is just a prettier.io's linter tool. It does a very opinionated version of markdown formatting. And I made no content changes except for in the, the, I think the contributor dot MD file was implemented in a way that was not marked down compatible. So I had to reformat it a little bit. What's that? I can't. It's a different file. Oh. I mean, it's in the PR here. I made it in governments. Here it is. Oh, governance. Okay. So this, this section. If you scroll down a bit, I had to change the member format. Like this list with a numbered space dash space. That's not markdown. Got it. So strictly syntactical change. Yep. I just added a dot and then I bolded the member voting member admin. Okay. Mark had a comment in there about maybe modifying the makefile, but then you said something in response. I don't think we should do that. Because it changes like this are, you don't know if it's done it right or not. So they're a human has to look at it. What's other repositories do is they have a robot that will make a PR that you can go and review and check in or. My, my, my comment wasn't to, you know, completely automate and check this in, in one fell swoop. What I wanted was just to document, what was the command to purify it so that if someone were to review it, they, we'd all be using the same command. Right. That, that command is in this PR and we could add that to the, some sort of document somewhere that says how you make a PR. Yeah, sure. Yeah, but we could definitely do that as a follow up PR to this. I assume. Okay. I love automation stuff like this. Anybody have any questions or concerns with this? No, thank you, Scott. Every time I make a change to the pros, I have to like do the like thing where you add bits of the file. So it seems great. So I, I'll, I'll pimp my tool a little bit. My personal GitHub, there's the repository called. Get tools. And I made a command called, so I extended get so I can run a command. So I can do get and it's lint and it'll auto based on file type run linters for you. So it's a, it's kind of cool. Just to be clear, you saw this at the get level. So I have a workflow that's like local to me, but I use prettier and it does this command that you see here. This is the one that just runs everywhere, but I used a version of this that only looks at your diff for your current commit and it runs lint on that. So I always check in stuff that's linted. Very cool. Yep. All right. Any questions, comments, concerns on this one. Hopefully Scott then sneak in something. I did not. There you go. Thank you. Thank you. Thank you. Thank you. Thank you. All right. I did remove Doug from the admin. That's wonderful to me. Thank you. All right. Any objection now has free time. Exactly. All right. Any objection to this one? All right. Approved. Thank you, Mr. Scott. Whoops. All right. Next one is mine. I don't think they've had really many comments on this one. This one is mine. It just added some text to the primer. I think. Yeah. Okay. This is the bulk of it right here. Basically, I just wanted to add some text to the primer, explaining some of the rationale or ideas behind the ID itself or the ID attribute itself. Basically pointing out the biggest thing here is that the ID is meant to be unique per cloud event within the scope of a single event. So that, for example, if a single occurrence generated to separate cloud events, those two cloud events get separate IDs. They do not share the same ID. If you want to do some sort of correlation and stuff like that, look at some other attribute to do it. But that's not what ID is for. The ID is strictly meant for uniqueness across cloud events from a single provider. What I did is down here, I replaced database commit ID with just a UUID because my concern was that someone can interpret this as one commit ID may actually generate more than one cloud event. Therefore it's okay to use that commit ID and more than one cloud event. And I didn't want to be able to make that mistake. And I don't want to get into that kind of pros in the spec itself. I'd rather leave that for up here, which is what I did. That's why I just changed it to ID or UUID. I'll leave that there for a second for you guys who may not have had a chance to read it. Okay. Okay. So what in the case of. You are doing transaction IDs. And you would like your, your middleware to provide you at least once delivery. Basically this change prevents. Using functionality that is at least once delivery mechanisms. Or at most once delivery mechanisms. Because there's no way to know what. What is the way to deliver it to a destination or not. You elaborate on why you think it would block something like that. Because if you replay the transaction commit history for a database and you don't have a way to know what. What the cloud. Cloud event ID should be. You can no longer guarantee you've not delivered that event before. So this doesn't say you can't use a database commit ID as the ID. What I'm saying is. If you have semantic rules that are trying to use this ID for some sort of correlation across cloud events. That's would be inappropriate. But it's not preventing you from using database ID. If it fits the, if it fits the rules of how we define this ID, meaning it's unique for all cloud events. From this producer. But you can do replays with this. It's not, it doesn't block that. Because it's replaying the exact same cloud event. It's not, it doesn't block it. Does that make sense? Yeah. Maybe I need to clarify that. We still have the trouble of if there are two producers that are reading from a non cloud event supported. Entity. No conflict. If the tuple is not there. Say that one more time. So above you're talking about uniqueness, right? And I still think that you need event. Type in the uniqueness check. So, so the reason I don't think we need type as of right now is because the spec specifically says ID must be unique from a producer from a producer. But if there are two producers producing events from the same source, right? You still don't know where that thing is coming from. You don't know if it's a replay or not. But if you have to, if you have two things generating cloud events from the same source, then each of those two things are responsible to make sure that their IDs are unique, right? No, because their IDs are informed by that, the entity they're reading from. So things are really replaying database commit transaction. And they're using the ID from the commit in the cloud event ID. Right. But I think, I think that's an implementation detail in the sense that if, if whatever mechanism they choose to use to generate the cloud event ID. That the entity needs to satisfy our requirements of it being unique. If they choose to use a field that's not going to be unique because there's another guy doing the exact same thing from the, you know, and, and going to spit out something with the exact same source, and they need to do some, some coordination to figure out what's, what's going on and how to resolve that. Right. I think that coordination is vent type. But that, but, but then you're talking about changing the definition of what ID is, right? So that particular source is always using the same ID, but sorry, the, that producer. Cause it's contained. It just happens that another producer is also using that same pool of data to pull IDs from. What if Christoph join in? He raised his hand for a sec. Yeah. I think I would try to discuss the issue before. So that it is, if the source is not really guaranteed to be unique, you can clash on the source. So for example, I have the same user handle on Twitter and on GitHub. So if both go and say there is a slash user slash Christoph, they may publish sort of events for the same source. And if you only look at the ID and you're really unlucky, they could also clash. So because they like Twitter and GitHub, do not know how the other generates their ID, but they would be different in the event type because one would become Twitter or something and the other would be come get up something. So in, in that scenario, looking at the type would then allow you to understand these are different events. But the other way to go is to say, okay, the source should also contain the UI and then you also don't run into this problem. So then we would explicitly have to make sure that people try to make the source are unique. Okay, so maybe I need to clarify something here. My purpose behind this PR was not to change the semantics of ID. It was to clarify what is currently in the spec. And I believe what's in here is accurate within what we currently have ID defined as in the spec, meaning we define ID to be unique for all cloud events from a single producer. If we want to change the definition of ID so that it's not unique and that the uniqueness spans multiple attributes, for example, type, then I think a different PR should address that. My PR is just trying to provide clarity for what is currently defined in the spec. Yeah, sorry, I may blow up the scope. Yeah, you're right. But I think it goes back to what Scott's talking about, because Scott, I'm not saying I think you're wrong in your concern, but I think what you're proposing to do is to change how we've currently defined ID. And I'm not saying whether I agree or disagree with that, but I think it's a different PR. Well, I read this as trying to clarify the conversation that's happening in the different PR around how to understand the uniqueness. Or maybe that's this one. No, I think they are definitely related. And this was just trying to provide clarity for what's currently there in the spec and based upon that other PR, this entire text may go away or change. So if you want, we can hold off on this PR until that one's resolved. That would make it feel better. I think they're linked and I think we should roll them into one or something because it's a bigger problem and I think we've been talking about it. Okay. I'm perfectly okay with that. I've no desire to rush this through. So in that case then, let me go back here for a sec. It's Alan's PR. I believe it's this one. In that case, that I think we may need to do is to go back and look at Alan's PR because I think. I don't think he necessarily took it upon himself to change the definition of ID. He was more looking at it in terms of given what's currently in the spec. How does someone establish uniqueness? Right. And I think what you're suggesting is maybe we need to revisit the definition of ID. Do I have that right? No, I'm not saying that the definition of ID is invalid. I think a single producer that produces an ID should be unique for its own scope. But the trouble is you can't guarantee the scope of every, every producer on a system. But that's what I, maybe I'm misunderstanding my interpretation. Let's get to the spec itself. It's actually looking at it. Where is, okay. So yeah, source and ID. Okay. So. Okay. So ID talks about. It must be unique within the scope of the producer. Right. And that, and while we don't actually, I'm not sure we actually come around and say this, but I think most people are assuming producer equates to source, which is why Alan's PR talks about linking these two for uniqueness. Oh, I guess it does right here. Describe the producer. Now this document, this in right here doesn't actually say that source has to unique across the entire world. Maybe that's something like that is missing from here. Or maybe. So I guess this bubbles up to the, sorry, totally clear. I work on K native. I write source adapters. I take things that are not cloud event native. And I bring them to a Kubernetes cluster. We've been using ID source and event type to understand the, the adapter that's read from a ultimate source, the source of truth, and then converted it into a cloud event in some scheme. We're making the choice to add. K native to the event type so that we understand which, which exact producer produced this version of the cloud event. And therefore if we look at all three fields, we can understand if there's multiple producers reading from say Twitter. And let's say you have a, for whatever reason, URL encodes everything. And another one uppercases all the events. It's modified, right? But they still have the same ID. And they still have the same source. So does Clemens subject PR playing this as well? It seems like it has to. If Clemens subject PR comes in, it'd be a four pole. As a result of that, I'm kind of wondering whether we need to take this offline and have a discussion about ID source, subject and type. Because it seems to me that we would probably make a mistake if we tried to modify or, or tweak the definition of just one of these without talking about all four in combination to see what we really want for the end game. I agree. Okay. Does anybody disagree with that? Because my next suggestion is going to be that we take it offline and set up a separate document or phone call or something to have some additional discussion.  Does anybody disagree with that direction or are we misreading the tea leaves here? Okay. Let's do that then. It is a very good discussion. And I don't want to do a partial job. Okay. I will take that one offline. All right. Next one is might as well. Okay. This one. Hold on. You're coming for a second Scott. Okay. I'm trying to remember why I wrote this. You are leading the witness. I'm trying to remember what the heck I wrote. It was a big one too. Okay. Tell you what, I don't want to waste your guys time. Let's take this one off. Let's save this for next time because I need to refresh my memory and page everything back in. It needs to get grouped into that doc that you have an action item for. Oh, we see. Are there previous discussions as well? That's right. Okay. That makes it even easier than for me. Okay. Cool. Oh, Clintons, you just joined the call. Excellent timing. Amins, would you like to talk about your subject one? I'm not sure if you introduced this in a previous call or not. I introduced as well ago, but then we saw it. We ended up introducing source in that discussion. Oh, yeah. You're going way far back. Yeah, of course I do. Because I also linked that. I think I linked that old, the old issue into this. So. In addition to what's written here. In addition to what's written here, there's also some supporting material that I'm pointing to that you might want to read. There's. I would say a little book available on, on that. The subject, but we have, we have already seen this in also in the demo discussion that we're having for, for the next coming up event in the EU is that in the demo scenario, this suddenly there was an object field or subject field that appeared. So basically the reason for the subject field is that in source, the source identifies where the data comes from, but the source itself may have some further substructure that you want to go and express in that events and sources typically a way for you to identify where an event comes from. In, in a scenario where you have, you're subscribing to multiple different sources of events and you want to land in a single function. And then you want to further, further understand what is that that in that source changed. So example. And that's the most popular one is you're subscribing to events raised by storage container. The directory. And you want to know when new files show up. So this is the block created event where we're generally talking about. You then want to know exactly which file was created. And you want to be able to generically filter on this, which means you want to probably put a suffix filter on that file name, which is dot JPEG. And you don't want to do this by cracking the payload, but you really want to have this in metadata. So now the way that how we've solved that problem for ourselves and Microsoft is where we have it. We have two fields, but for cloud events is to go and put the source to construct the source from the place where we subscribe, which we call the topic. And then we put the pound, the pound sign, the anchor effectively at the end of that. And then we append the file name. And then basically to go and do some reasonable filtering on just the filing with prefix suffix, we basically have to know that we can break apart that your eye at the pound sign and then kind of come out without two fields. And that is the left part being the container and the right part being the file name. But that seems to be, so that turns out to be for several people who have been, who have been starting to implement cloud events or also middleware for cloud events. And that duality where you need to have information about where does that event come from and then further information about what aspect of that source has been, has that event been raised about is something that is, is in fact interesting to people. So that's why I'm effectively reintroducing this, even though we've had been discussing this for about a year ago, I think, and then ended up having just one field. I think we're now having started to have some evidence that having source as the subscription scope, if you will, and then subject as the additional identifier for the sub object that the event is really about makes sense. Thank you. Any questions on this one? This is a rather large chain. So I'm hoping to get at least a little discussion going here. I like it. Scott was, Scott was saying, give me, give me, give me. So some, some support, some more words to that would be nice. Yeah, we're, so in Knative, we're trying to work on, well, on the eventing side, we're coming to the need of some sort of registry. And they're, if you, if you're going to ask all of the consumers to send to a central place and then ask that central place, give me all events that match the following criteria.  But I want to only know for a very specific bucket at the moment, we have no way to do that because we don't control the format of what a source is. And we don't know that we can always split on a hashtag or a pound sign. So we need some, something that means the, the parent object and the, the subject, which this, this fulfills. So we've actually started working on implementing this as an extension because we need it. And I also want to comment on this one. I also think this is quite, quite needed for every single example I've now given for other PRs and features I've had to somehow work around this issue. And I think that shows that. Well, it's an issue. Okay. Sorry, I have one more point. If this comes in, does source change? Well, I was going to get to that in a minute because I think Clemens missed the previous conversation. I was going to say was if we actually liked this PR, then we can't merge it today. We need to pull this into the previous conversation of how does this relate to ID and then as you said, Scott has this impact source. I think we need to take out all those together first before we go about merging this one. So I don't think it changes source because source is, I can imagine that what sort of discussions you might have had about uniqueness of, of, of messages or of events, but source is really the place, the place that you, where you, for which you register interest, right in the pop-up substance that raised those events. And then subject is really a thing that is, that is relative to that source. That's, that's how I look at it. But source per se, I don't think source as a definition of how we look at it. It's the thing that raises the events. It's just that the source itself has some internal structure and you're interested in, in what, what is that inside of that source that just, that this event is about? And that's something that the source itself can't explain really because the source is, well, the thing that's raising the events, it's the outer container, if you will. Can you show comments and look at the comments that I made at the very bottom, I think? Yeah, I'll do that. Just, yeah, let me just point out, Clemens, but if nothing else, when we need to do things like change the examples so we don't include pull request number one, two, three anymore in there? Yeah. I think that's a, that was, there were some brilliant examples in the, actually in here, in that the, if you subscribe to pull requests, so you're interested in pull requests, let's just look at the highlighted piece, right? What you will subscribe on is on the cloud events repositories pull request source, right? That's what, that's what you will subscribe on. And, and when you get events, that's how you will discriminate them from other events, because you're going to look at this and say, so you're going to have your, your pull request notification service. The first half is, I want to know, I want to identify which repository they are associated with. That's the left side of this. That's the thing you subscribe to. That's that, exactly. So you can tell from this which bucket they belong to, but the last part of that, the one, two, three is not what you subscribed to, but that's effectively what this event, this event is specifically about one, two, three, that new thing that you didn't know about when you subscribed, because it didn't exist yet, but that now comes into being. That's the subject of, that's the subject of this event, which has a certain type, which has a certain idea, et cetera. But about that subject of the event, you can obviously raise two, three, four, five different types. So why this is not the type and it's not the source. But yeah, we're going to have to go and change those. Okay, Scott, what do you want me to scroll to? I think there's an example of that. Maybe the last comment here. Yeah, that's exactly here. And the wonderful thing is the last, the last example that Scott mentioned is the email to with the subject help. That's exactly what that is. Right. This is, this is why the messaging system, including SMTP have a subject because in addition to the address, where that stuff comes from, you still need to have some, some sorting criteria, how someone can go and figure out whether it's worth reading and often that's the subject. Should that, well, I'm just wondering for SMTP, should that be subject or should that be something like a thread ID or something like that? Well, so, so SMTP lands effectively in your inbox is a thing that you look at. Because that's for human consumption. The subject is exactly what you typically look at. And that's also how your threads are being sorted by. I can have two threads with the same subject. They get threaded separately because they were actually sent independently and, you know, health is a great example. If 10 people send help over the next two weeks, they may not be replying to each other. They may actually be asking, you know, for help on separate topics. I would argue that's a tangent of correlation. But effectively, this is, this is about how you tell it's a subdivision of, so the source here, which is the serverless working for mailing list is sending you events because you're subscribed to those. And now you want to be able to tell those apart and the way that you tell those apart, if you look at it in your mail, in your mail application, is using the subject. And yes, there might be a further criterion with the thread ID, which then allows the client to go and, and, and figure, and figure that out. But that's a, that's an additional correlation picture. I have a question. How does this. So I am concerned about making something like the pub sub channel or the Kafka topic or something like that, like baking that in, in a way that like seems like not like people will be using not Kafka or not pub sub. And I want to make sure that this is like something that works for everybody. And it reminds me a lot of the conversation we had about topic, which was an attribute proposed. I don't know, like a year and a half ago or something. What is the different, like, how is this different than the conversation we had around topic? And I think, I think what, I think the thing that got in the topic discussion. The, the, what, what caused most confusion is that the topic is necessarily a thing that is a middleware construct. At least, at least in the way how it's usually perceived. And now I'm already need deep into messaging philosophy. The source. But I think that, I think that like we're already into messaging philosophy is like the important point here. Right? Like we are, we're baking in like a messaging paradigm. So I'm, I'm, I think we're matter of what we're doing here is which we're, we're baking in a, a dispatch, a dispatch network. When you just assume, forget the, forget who is, forget whether there's middleware in play. Right? You're simply, you have a function and you are asking 10 parties to send you something and they, they sent you something about, let's stick with the, they created files example. Right? So you have 10 parties who all manage files and they tell you about it. So now they show up with cognitive events. The first thing you will look at to figure out what to do with that event is you're going to look at source because you want to know who just sent you something. And then now the second thing is you want to know what is that file that was created and whether you're interested in that file that has been created. Now, so you now need to go and be able to apply a filter on some metadata of, of whether you are interested in that file. Is that file, if that is about a JPEG, you might be interested. If that's about something else, you might not be interested. So you need to have a, have a, have a screen that carries that information. And that is distinct from the, the information about who sent you that, who sent you that data. That's the decision I'm trying to draw here. So it's not necessarily something that's important for middleware, but it's important for, for someone who's, who wants to distinguish between who sent me this, that's the source. And what is this about? And that's the subject. Okay. Like I understand the need for this, like for, for having something that describes the content. And I would love for the content, for like the description of this attribute to have more of what we've talked about in here. Like to, to make that, like that distinction clear. Do you think that it does? Well, it does me. I wrote it. Okay. How about I take an action item to leave some comments on this PR and say, like, like I am like, bringing it back into the, on everything, like, everything. My, my main concern, and I know I sound like a broken record is that I want this to not just work for like the example use cases that we are thinking of, but work for like more general use cases. And I worry that we are baking in, you must be using Pub sub or something like that for like, in this one. So maybe I can go through and add comments. Or maybe just like propose an additional. Like paragraph at the end that says that it's not It doesn't correlate exactly to a PubSub channel. It doesn't have to. It can be used for other things. So would that be okay? But one thing you could also look at that is potentially adding something to the primer, right? Cause typically the spec is relatively short and even when you start talking about pros, that's perfect material for primary. But I think it's about this attribute specifically, that like, that this, that subject is not meant to be used as a, like only as a PubSub channel. Yeah, but that's, yeah, that's not what, yes. Okay, I understand, like I'm too deep in this. Like this is my, I'm probably 20 years too far into this whole PubSub stuff. The thing that I don't see the thing that you're missing. And I would like to see the thing that you're missing in writing. So that would be fantastic if you would do that. Okay. And one, if you do me one favor, as you, as you think about this, there's in the comments, basically in the PR itself, I've leaked the old issue, which is prior, basically I created an issue back in the day, which was subjects, I think topics and subjects and, or just subject prior art. And that's leaked from this issue. And then if you scroll further down, kind of five pages down, it's the issue text. I have a list of like, Doug, if you could, if you could It's in the conversation. If you go in conversation and go, go for, go up, I put that into the right, into the, up, up, up, up, up, into my original text. One 12, then I'll above that, that's linked that one. Yes. And then scroll down, there's a whole prior art section on where actually linked the various different kinds of products and definitions of, of, of subject. This is one of your, this is one of your shorter comments, I see. Yeah, I did. Sorry. Basically just show it, this basically just, live with further, no, because there's actually a table. Eric, there we go. So this is basically that subject field and how that subject field is, looks in various different kinds of infrastructures. So that's kind of the summary of, of that, that's not something that we're introducing here, but that, that's something that is, is very common in the, in the infrastructures. So I have a, for me, that's, for me, it's that, that field for me is basically given as something that in my head must exist in a message. And I understand that if you come from a different, from a different angle that it might not have to. So, so, but I, in my head, I have a hard time closing that gap. Rachel, if you would help me closing that gap with some additional text, it would be fantastic. Okay. I'll read through this and add comments and I'll also read through this topic, subject, prior. Thank you. Okay. So, hold on, where are we? Anybody's hand up? I don't think so. Okay. I got a question for Clemens. I think the answer is no, but I want to double check. Are there any other constraints we need to put on this around uniqueness or anything like that? No. This can be literally anything. This is, whatever the source things is the right thing to say here is fair game. Okay. Anybody have any questions, comments? Evan, you've been putting some stuff in the chat. Do you want to vocalize those or let those go? Oh, just that I was slightly concerned about saying that subject or that source was related to how the message was published specifically because if we're ending up forwarding these messages, it seems like needing knowledge of what the original publisher was doesn't have a good decoupling between producer and consumer. And so I'd rather have source be some indication of the source system. Now, it may be the in Clemens system, the source system is the PubSubbus, you know, is PubSubbus, but I'm not sure if that's universal. So I just wanted to clarify the difference between the first place it got published and where the event originated. Yeah. And this is, that's the place where it goes into this. This is where the philosophical piece comes in. And that's actually where, I think where we landed on source and where I'm actually happy with that being source. Because topic is something, because topic is an overloaded term. So let me back up one. The way how, the way how topic is being described as an abstract term, which means is, this is the general, this is the channel, the logical channel for which I deliver events and where subscribe events is as an identifier is something that is, I think that's still true, that that's a good concept. However, since topic is also used and largely mostly used as a concept that is a thing in a PubSub infrastructure, then you get to the point of, okay, so the topic is where I send that message and then I pull that out of the message and now I do multi hop routing and I now put that onto a different topic, different topic, how much is that worth that I put the initial topic where I publish that thing into that event? And that's something where even in our team, in the event group team, we're now actually explicitly into the native schema adding source because we have now realized that using the topic because of that overloaded notion is probably not too smart. So yeah, so the topic will not be useful but source really designates who ultimately put that event out and that is a channel. So looking at the description of source right now and the examples, a couple of things that I think based on the chat may have caused some confusion is the optimist will include things like the process to produce the event and some unique identifiers. And then in our examples, we show specific like pull requests for example or a specific resource in an API. If instead that we said this was a representation of the source system and then it shouldn't include unique identifiers and those should go in subject, I think that the confusion would be substantially reduced in the spec. I agree with you. Okay. Yeah, I can agree. Yeah, because so what I've been, since this is something that I've been reintroducing and we've been having long discussions about this prior, I wanted to make the PR theory scope and not edit the rest of the spec completely but I agree with you. So with if we introduce this then that needs to go with some edits throughout the rest of the spec to basically make clear what the relationship needs sort of the subject is. Okay, so since we're having a long time and since Clement, you missed the previous conversation because of your other phone call. I will listen to the recording about that. Well, the key point is we've realized that we probably need to have a separate discussion that sort of combines ID, source, subject and type because based upon all of the various PRs and issues that are out there right now it seems like we maybe get converging on this idea of we need to modify some or all of those four different attributes in terms of definitions or in the case of subject, add it to the list and when you add this one it's gonna impact the other. So I took the action item to create a separate discussion to sort of have that broader discussion to resolve those four attributes in combination so we don't do one PR that's in conflict with another. We're gonna do it all in one gigantic blob basically. Yay! Yeah, so. Okay, so let me ask this though since we're all set of time does anybody have a fundamental objection to even considering something like subject? No, I think we absolutely need something like subject. Okay. Cool, thank you, Rachel. I have a fundamental objection to not considering subject. Thank you, Tafini, I appreciate that. I just wanna make sure that we head down this path and someone doesn't wanna raise their hand and say, wait, wait, you guys are going the wrong direction. Okay, cool. Let's circle back to the ever popular attendee list. Just to make sure everybody, Matt, are you still there? Yes, I am. All right, Victor, are you there? Victor, Victor? What about David Lyle? Yes, I'm here. Barron? Barron, are you there? What about Klaus? Yeah, yes, I'm here, sorry. Okay, that was Barron. Yes, I'm here and this is Klaus. Okay, and Victor. Okay, did I miss anybody? Yeah, I think you missed me. Oh, darn it, okay. Anybody else? Okay, in that case, I believe we're done right at the top of the hour. Thank you guys very much. If you'd like to hang on, for those of you who wanna talk about what's going on at the demo prep call that we have basically starting right now, you're free to join. Otherwise, everybody else, we'll talk next week. Thank you guys very much. I have, okay. Okay, Rachel, go ahead. Everyone can go. I just wanna say like there's


What's up, Liberty family? It's your girl Ari Chambers here, and I am live at the Barclays Center because the Liberty has some new additions this year. Let's talk to some New Yorkers and see what they feel about it. Come on. Excuse me, sir. You seem to have Liberty gear decked out in the middle of winter time. I'm just feeling the warmth of, uh, Stewart, New York City. Yeah, Stewart, New York City, baby. She coming out here, we live. Stewart, welcome home, baby. We live Liberty culture. We are Liberty culture. Sleeeeeeep! We need that. We needed an all-time assist leader on our team, VanderSloot. We got the scoring, the MVPs, JJ, Stewie. This is what we needed to build a dynasty in Brooklyn, a seafoam dynasty. Pitta! Pitta! Everything! Bow! New York basketball is back on all three levels. We have the best players in the world coming to play the best basketball in the world. And people come here to play their best, but now they got to come here and play their best against the best. We back, baby.  You too, because it's cold. I'm so sorry to be... We heated up this summer. We get the chip, baby! We get the chip, baby! What do you anticipate the team being like? Fun to watch, scoring a lot of points, and playing great defense. Oh, it's... Time to take the city over. It's go time. Time to get to work. It's our year to win the chip. We got a big front court, heavy. Don't mess around and own the crown. Sleew! Welcome to Barclay Center. Welcome to New York basketball. We are excited to have you. We need you to lead us to the promised land. What do you see for the Liberty this season? Championship. But it's going to be a championship coming this season. I'm saying that right now. That's right. We're winning the WMAH and we're going after Las Vegas too.


Good morning, Sub-Traders! Happy Wednesday! On the 19th of September, how's everybody doing? Good to see you, Mark, Amy, Lawrence, Donna, James, Grant. Look at all these great people. Tim, Joanna, Craig, look at these great names. And I hope everyone is having a wonderful, wonderful, profitable day since yesterday, my God, T-L-R-Y. Who would ever thought this stock would go to $240? Is it something like that? Who would ever thought? And let me just tell you one very important thing, okay? A lot of you come to Cybertrain University and I just want to kind of point this out that, and there's a lot of people that can go through the names. You guys can sit there and you can chat away and tell me who did well and who made money on it. But I told you this a long time ago. When we trade and when we day trade, okay, we'll find another one. If it was like an Elfin, if it was like a DRYS, if it was, I mean, the list goes on and on.  And people like, ah, I heard a bit, but I never seen one. Well, you know what? People are starting to see it now because they're seeing it on TV. They're watching CNBC, T-L-R-Y. The CEO was on yesterday. And the funny thing is we were trading this at $20.  I wish I still had my 1,000 shares at 24. But you know what? At the end of the day, I probably would have sold it at like, I mean, I made a lot of money on it. I mean, a lot of money on it. But you know how it goes. You buy as it goes up. And you know what? It's getting more and more crazy. So, you know, getting out and buying it back, like with so many of you guys did yesterday, that's what it was about. I mean, who did pretty well? I mean, just a couple of shout-outs. Steve Dee, he made $15 on it. $15. Guys, on 1,000 shares, that's $15,000.  You're not doing it with Amazon. You're not doing it with Facebook. You're not doing it with Tesla. You know, you're doing it here at Cybertrain University. And you know what? I had so many students out there and I told you, give us a chance. Let me show you how to play the game.  I know you guys didn't want to do that. And it says, trust me, I will make your money back. You'll be very successful. Just watch and let me teach you, like you're learning in the classes, like we're doing right now in all our classes. And we are going to, we're going to find something and we're going to make money together in a trading room.  And guys, let me just tell you this. There's going to be another one. There's going to be another one. We do this, I mean, we'll get one of these probably like once a month. You know what I mean? So don't even worry about it. Don't even worry about it. They're there all the time. Yes, Brad, it is definitely a huge short squeeze from what I saw. So somebody's getting squeezed. And if you want to learn more about that on my videos, I think I have one on YouTube about short squeeze. Way to go, Steve. I was busy yet, made it in one trade. Made $2.25. But you know what, guys, look at the points. Look at this great stuff you guys are doing. I mean, everybody out there, Lita made money, was in it. Was that feel great to be in it? Ben did great. Ken did great. You know, all you guys were in this position. It just feels good. And I told you, what did I say yesterday? Buy one stinking share of it. Just buy one share.  Know what it's like to be in a winning trade. It's not about making money. It's about saying, wow, I did trade TLRY. And then when the foul still finds another one, I won't be scared. I'll be a chicken. I'll jump in. I won't be a dear in the headlines. And that's how you make money, guys. That's why we're here. We're not here to watch. We're here to work together and make money like a team. Because that's what CTU is all about. We're a community. We're just not here to teach you on your own. And say, okay, you go figure it out. And let's just watch fouls still make money. No. It's about us showing you how to do it and figure on your own.  So I want to give everybody, not no one specifically, but everyone here a huge round of applause. And you guys all give you a good round of applause. All right, now there were a couple of the stocks that we did trade yesterday. So even at TLRY, I know some of you are beginners and like, hey, I couldn't have traded. Guys, there was a bunch of other ones you guys did pretty well on, right? What about the VKTX trade? Let me bring up that one. VKTX, there we go. Okay, another one right out of the gate. And it was a great short, Viking therapy. That thing gapped up huge yesterday. That thing was great. N-B-E-V, how about that one? Which is back on the watch list this morning. Which, by the way, some of you saw the announcement. I know a lot of you guys are liking it. But I'm in this trading room. I'm doing my homework for you at 7.30 in the morning. That's two hours before the market opens up. And I put the watch list out there. And I made the announcement, I told you. And look, if you look at any one of those stocks, if you jumped in any one of them, you would have made money on it. So anyway, there was another one. And I'm glad you guys are liking the pre-market picks. And like I said, we're trying to make things get you guys more aggressive, get understanding, because we make most of our money in the pre-market. Another big winner, the C-R-O-N, which, by the way, it's back on the watch list. Look how beautiful that stock went. $10.50 all the way to $12. Listen, by 10 o'clock, within 30 minutes, within 30 minutes, stock went from $10 all the way to about $11.50. If you just got half of that, you would have made your days paid. And once again, back in the watch list again. So a lot of good stocks going on, guys. And we got a new list to go on this morning. So remember, the past is the past. And now we got to focus on what we're doing this morning. All right? And you know what? Some of you guys already did well today. Who made money this morning already? It's so great to be profitable for the market if it opens up, right? And it's just great. NBEV, Ken's shouting. You love that one, right? Ken already made money on the trade. Ben already made my IGC. Look at that, we've got tons of them. So anyway, let's talk about the big winners again. So let's start off with the TLRY. What are we doing with this TLRY? I spelt it wrong. Anyway, guys, you can't obviously, if you're not an advanced trader, you've got to stay away from it. Just watch and watch the traders, the ones that are in class, the students, the gold students, and see how they're profiting from this one. See how they get in, how they take the money, how they get out of it. But this is what it's all about, what we're watching right here, and to get to this level. But don't worry about it. There's a lot of other ones in TLRY. But that one's been great. So that one's going back on the watch list. NBEV, another one that's on the watch list. You guys are doing great on that one. NBEV, nice push. Yesterday had a big move, it's doing it again. Right up everyone's alley, cheap stock, 2 million shares already traded. Look at the matrix on the right. Look at gold, those great iceberg orders. Phenomenal. One that's going to spill into today from yesterday. C-R-O-N, another nice little move. It's got some little shakes here and there. It does got these 5-10 shakes that move. You could see it moving 3.4 million shares already traded. But that would obviously make in the watch list. SPWR, another one I found this morning. Beautiful little move, great move from yesterday. Things picking up again today. Up 7%, not the crazy amount of shares. More than enough, 173,000 already traded. Look at those iceberg orders, 3,000. Look at focus on those resistance levels. Focus on the high-frequency trades. That is how we make money. Next one which all of you guys are talking about right now. This one was a joke. IGC, I gave it to you yesterday. I said, you know what? The problem with IGC, it was slow and you got to trade a lot of shares of it. If you bought 10,000 shares of this stock, that's a $16,000 investment. That's like buying a $16 stock. And if it moves up a penny, you make $100. This morning, look at that. Already people are already making money. If you bought a thousand shares, you're already up about $100 already. This is what we do. Once again, probably the most comfortable and easy stock that everyone should be trading, which is what we're looking at right now. Everyone should have been in this stock. This stock is just very tradable. It's got a great spread. It's got great orders. Everything that you're looking for. CGC, another one. Big mover yesterday. Had a nice little pop. Had a couple of nasty shakes here and there, but she did really good this morning. She's gapping up pretty nice. Only issue, she's a little more on the expensive side. Spreads a little big. You better be a level three trader or up to trade this stock. And then I thought I was going to throw this back in there. I don't know how well it's doing, but yesterday I saw when it was doing pretty well. I don't know. Maybe I'll take it off the list. Things change. It was gapped up pretty nicely. Probably going to take it out. We got one, two, three, four, five, six movers today. If you were here earlier, you probably already made a lot of money already. But I do want to remind you guys, today is a holiday. Market is obviously open, but it is young Kapoor. Today, kids are all from school. My kids are all from school running around and driving my wife crazy, but that's okay because I'm here working with you guys. That's what's nice about going to work. But anyway, right back in the middle of a Wednesday, it's a very awkward time for the kids to be off, which will also affect the market. So you might not see a lot of action, but we did see a lot of action in the market. Dow Jones was phenomenal yesterday. We're breaking these highs. The tariffs are kicking in, but do keep in mind, it is a holiday, so you might not get too much news going out with corporations, but we do got some good action so far. Alright guys, anything I'm missing, I did not call out. Neil made 15 cents already on CRON. Let's give him a round of applause. Congrats, Neil. Alright. James already made money trading at NBEV in the pre-market. Beautiful. It's all about the pre-market. We've got to get in before the rookies put their orders on their online brokers account so we can follow what the market makers are doing and that's what it's about. Alright guys, so that's our list. Busy, busy day. Just a couple last minute announcements. Okay, last minute announcements. You got class today, don't forget. Remember, phase one and phase two, and then next week, Monday and Tuesday we're doing their mastery class. I was invited again to go there so hopefully some of you are going to be down in the Florida area and they're going to have mastery class. I will be there on Thursday doing and talking about exclusively on the matrix. So we got a lot of classes going on and then tomorrow we got open house. We're going to try to recruit more traders. Once again, let's go out there and show them how well we're doing it, why we're the best in the industry, and hopefully the more we educate, the more that learns, the more we're going to be part of the team, the more and easier life is going to be. Because remember, that's the reason why I started CTU. It's about going out there teaching you guys to make my life easier and you're doing a pretty damn good job doing it. Now you need to do the same and you've got to get that pyramid of people out there underneath us. Because remember, there are over 10 to 25 million people out there trading and it's amazing how many people are self-taught and don't really want to get involved. They rather learn and lose money than be part of a team and that's okay. We'll just trade against them unfortunately. Guys, good luck, happy trading. See you in class and then we'll see you back in the afternoon meeting and don't forget, early bird gets the money. See you early in the morning in pre-market. Good luck everyone, happy trading.