hey everyone welcome to aether gazer and sorry i wasn't able to stream last night or early this morning it was actually 12 midnight when we had the launch in global here in the philippine so i had to forego that but when it launched i played and played probably for two hours if i can recall and when i woke up this morning another you know another run wherein i you know was able to test out and give you guys my first impressions okay so first and foremost if you can see here the ui is is actually very simple it's um placed as usual it's it's not really that clean but it's it's actually very functional so you have here settings you have here this i think your daily sign in and the like missions are here mail chat friends up above you have your energy which is this one you have your credits here or your gold this is your summon currency um this one is called shifted star the other one this is your premium currency which is flower something shifting flowers okay so those are your currency guys and that is how we spend you know for the game you have your banners here of course and so far we haven't had any codes yet so i'm wondering when they're going to be putting out codes for the community so i'm actually i was like actually expecting codes because they have um they have um what do you call this they have given rewards already but no codes so far okay so um again energy for this game is a bit a bit scarce um i'm not actually um i'm not actually uh what do you call this i'm not actually relying on these these are your top up for your energy so if that runs out i'm sure everybody will run out of energy but again the game has little energy kind of similar to he got a ruthill in terms of energy um the gotcha system let's uh go to the gotcha system here so these are your banners here let's go here so you currently have three banners here so one two three this is for your weapon kind of a attachment to your weapon but it's also a gotcha system which i don't really like but these are your main banners this is your limited banner here this is your rate up banner okay so this is with a different currency so shinry and uh rahu is also with a different currency but you can use your shifting a shifting star if you need to summon for both banners okay so the gotcha system is um as you can see your s-grade modifier guaranteed within 30 scans or pulls which is actually impressive so the pity is only up to 70 and you can actually monitor your summon history here every page is 10 so i'm now up to 70 for this banner so you can actually monitor what you have pulled and how many you have pulled so far so i'm liking the gotcha system except for the gotcha system for the equipment and um let's go back to the main uh main ui so this is actually where you do all your farming you have challenges here these are these are uh content that are unique from each other this one is farming for sigil which is kind of your gear not your weapon this is for your supplies for your level up and this is going to be for your main story okay and we have your of course inventory your guild so far i joined the guild but i left i'm gonna be joining a guild in my tomorrow because there's a cooldown of 24 hours um and also you have your functor this is the one that i mean that that that i meant that is actually in a gotcha banner so the functor is actually linked to your weapon we'll go to the weapon in a while we all they also have a meow this is kind of a an additional um uh companion with buffs and abilities so you have to choose wisely on what effects you need for your team which is actually perfect for you as you go along the story you can unlock each and every one of them okay so they carry buffs for your team depending on what team you have you have scan and your um your characters are called modifiers okay for the modifier uh of course this are your basic stats your skills are here they usually scale depending on the level of the character depending on the level of the account as well you have ultimate skill chain so if you have two or three characters that are good with an ultimate skill chain they will actually proc instead of only one character in the skill chain or more or less it's going to be more powerful if the ultimate skill chain takes effect so either two characters are involved or three okay access key this is what i was mentioning so this is their weapon but this is the one that i mentioned that is in that gotcha banner so this one i don't really like this because again there will be two gotcha systems that you will be rolling for or summoning for every time so i'm not sure but again this i think the only thing that i don't like sigils are buffs um i i you know i treat them as gears they have skill set effects so you have to have three of each for you know for a set effect to take effect and the codes are here this is kind of your skilled tree you have to open them and you can actually use only a um an imprint so an imprint is actually a line of code that you can only use so once you take out an imprint and you select another imprint then you'll be using those set of skills uh or activate those set of skills okay so as for the character design um it's a bit pgr i wouldn't you know i wouldn't lie um you know to you guys it's my opinion it's it's a little bit pgr but i don't really mind it um that's not why i'm actually playing this game it's the the gameplay is a bit similar yet different from pgr so let's go to one gameplay here guys and i'll you know i'll show you what i mean for those who have not played this game and for those who are still you know uh thinking of playing this game so we're going through the story so these are so you have 40 here so let's depart i'm gonna be using my mobile here um so that let's do one more of this one let's really clear this because i want to see i want you guys to see all three characters so you have three there obviously you have your combat power up there so for your combat power um again as you level them up they go up as well this is what i mean the ultimate skill chain so i have one skill chain up uh activated which is the uppermost so we'll demo that later then this is your companion here so i opted for that guy and you can actually select three so the two others will be controlled by ai and the main team leader will be controlled by you okay so this is what i like about this game because it's not really you don't really have to switch within battle for you to reuse them or for you for them to assist you they will be controlled by ai so let's move forward here and engage this one and let us see how we're gonna be playing this okay so let's just skip this one so as you can see here it's kind of really similar with pgr it has a different mechanic to it in terms of uh the dodging is similar but the active skill you can combo the active skill if you want every character has a different combo for their active skill so take note of that because it will really play a big role on which character you want to eventually play and you want to stick with okay so i would suggest that you practice with one or two characters for their skill combo the skill combo is the buttons they're the four starting from the second from you know from below so this is actually going to be your ultimate skill chain so i'm gonna be activating it and we have another one another ultimate but technically you have a lot of ultimates i think you'll have you'll be having two at least so there you go so what i'm saying is there are a lot of a lot of skills to learn really when it comes to your your team combos active skill combos there it's going it's going to be there in the tutorial so again this is actually if you compare with pgr i like this more it's not really that hard to play this game not really a lot of combos to take note of not a lot of switches in terms of characters and i think it's it's more fun to have three rather than only have one in a battle so again i like the format i like it better i'm gonna be sticking with this for probably the next few months and see how i progress so far so i played already for one whole day and i'm actually liking this game i will stick to it and probably give you guides guys in the next few days and also if you have played this game already aether gazer what are your thoughts is it similar to pgr is it a game on its own what do you think of the gameplay versus pgr what do you think of the characters me i prefer this over pgr i think i had it it took a lot of my time playing pgr because there was a lot to learn the learning curve is actually very big but for this one um probably get give you a day or two then you could understand the system already so that is it guys for my first impression so comment down below also put a like to this video if you find it informative so thank you very much guys for staying as far take care stay safe this is the warden and i'm out of here


Good morning everybody bet the fishing here today. I will be reviewing the egg zone adrenaline bug black and blue color I will be flipping and pitching all the way across this lake So stay tuned guys and let's see how these product perform Exxon lures Pro-series adrenaline bug will I catch any bass with this I Guess you gotta stay tuned to find out Baby, let's go Another one on the egg zone Adrenaline bug This one feels decent baby. Let's go. This one feels good. God. This one feels good, baby I better not lose this one. Oh my god. This one feels good Come on. Come on. Come on.   Thank God. I'll pull him up bro. I'm not playing bro You know how we do baby. Look at his good bass, baby Look at the mouth on these beast Heavy too, bro Healthy bass man Healthy bass man on the adrenaline bug By egg zones On the adrenaline bug, baby. Let's go man Let me revive him man for a little bit He's ready to go. Damn man. Ah, man. Good bass, baby. Let's go Thank you for buying baby. You know how we do man On the adrenaline bug man by egg zone. Let's go baby. You know how we do I'm giving one of this another bass On the egg zone adrenaline bug Nice flipping lure. I don't get loose, baby. Let's go man. Another bass Go get over here, man. Quit playing on the adrenaline bug Let's go, baby. Ah blue color man Black and blue flipping color man Bass Yeah Let's go baby.  Nobody want to eat fish. I know if you want fish you just buy it. Oh Yeah, they got the carbs Yeah, the one that they'll be jumping what is this? Oh, this is our bass. Yeah. Oh, no, but Thank you so much. Enjoy your day. All right. Enjoy your day miss. God man. He's stuck really good man.   Oh, man got the plies Get over here.  My favorite lake man to fish I always kill over here man on the lake Now I'm in Central Park, man Bro, I ain't playing man. Adrenaline bug man.  This inside man with a good belly Let's go for the quick lease man.   Let's go man. Hey, we having fun man. That's all about man having fun, bro All right, so I'm gonna show you how I rig the egg zone a general in bug first I Get a Baba stopper Max I get a weight 316 ounce I'm doing a Texas rig.  So, you know, you get her over here right in the center Perfect perfect and perfect man, you know Perfect setup Let's go for more bass man, but the fishing here stay tuned guys eggs on a general in bug Texas rig style There must be a bass around here man on this cover It's got to be one or two I'm still flipping The eggs on a general in bug bluish color Hoping to get a bass around here man We need another one It's been like 30 minutes Since the last bass I was just walking across from all the way over there I've been flipping all corners Of this lake and man not in math can't believe this This look perfect like a bass hideout Come on eggs on Let's get another one I'll be back guys Stay tuned Let's go baby Got him Over here on the edge With the eggs on a general in bug Blue color Oh, this one feels good, baby. This one feels decent. Don't jump, baby. Come on, man I don't want to lose the lure man get over here Another old bass Quit jumping man Get over here, bro That's what I'm talking about man Let's go, baby Home door general in bug man bluish color man. We're killing it today, man So I'm talking about man Doing a review On this lure man by eggs on let me see man. Yes. There you go, man Back out of mind I had to switch the weight Because I got stuck on the last one so I lost all of them. So I'm putting a barrel weight man That's all I have man, you know, man. We improvising. So, you know Damn man. The hook just came out man A general in bug, baby. I know the good bass man Over here, bro, you know, man Then this back this bass being caught before look Thank you for biting, baby, you know, man Damn, look at the tail man. Don't mess up Eggs on baby doing work man A general in bug man bluish color man Y'all better get that man Good product man They got all type of color man. They got blue blue gill black and blue flake green pumpkin Watermelon watermelon red flake Oh man, all type of all type of colors man, you know, I mean just go to their website And check out their products man This they sell all type of lures man, you know, I mean Well right now We reviewing The general in bug bluish color So Look at this man. I know the good bass man. All right, man. Let's go for the release on this guy, man I got some pictures And everything for my instagram, you know, I mean better fishing Let's go for this bass man There he goes, man Thank you for biting little dude Good bass man. Good bass over here on the axon, baby. Let's go another one, baby. Let's go.  Come on. Get out. Get away from there. Get away from there Get away from there. Let's go, baby You gotta lose Get over here, man. Another one. Do a general in bug man by axon The blue color get over here get over here another good bass, baby Get over here Ah, man, don't get loose. Don't get loose. Let's go, baby. That's what I'm talking about, baby Another good bass, baby Let's go, baby axon, man It's putting in work, man Well, not that big, but hey Almost hitting one pound, man I'll take any time man when the body's hard, man. Come on hook. So I'm talking about man Go little bass man.  I'll be recording Let's go for the quick release, man. I don't even need a picture on this one, man Oh man, I don't want to fall down, bro Let me lay him over here And then revive him. He goes, man. There he goes Perfectly fine, man Perfectly fine, man Cut him over there, man On the axon, man A general in bug Blue color Let's go for more, man, but the fishing here, man Axon putting in work, man Got one hooked up. Stop jumping, baby On the axon lower Come on. I don't want to lose that crow, man That bug Look over here Ah, it's cool, baby That's what I'm talking about On the general in bug, man Killing me Just killing it, man So I'm talking about, baby On the general in bug, baby All day, baby. All day Another good bass, baby. Not that big, but Almost hitting one pound, man I'll take any time, man Any time of the week, man. I'll take it As you can see My Wait, let me release this bass right now first Before I explain Day goes, man Day goes Good bass, baby. Let's go for the release Damn, bro.


I'm going to move my seat less, ready? So my seat's going to move less. I'm going to squeeze the rain like water out of a sponge.   But I'm going to do it in an ask and release manner. And look what I got.


Good morning Hank, it's Tuesday, so one night about 15 years ago I went to a bar in Chicago and through a mutual friend I made the acquaintance of a mathematician named Daniel Biss. I was surprised by how much I enjoyed talking to Daniel that evening. On account of how throughout my life I had worked pretty hard to avoid interactions with professional mathematicians, like I chose the college I attended in part because you didn't have to take math to graduate. Also it's hard to make friends in adulthood, and I've never been good at it, but as Daniel and I played an exceptionally poor game of pool that night, I had the feeling that I was making a friend. And it turns out I was right, Daniel and I have now been friends for more than a third of our lives.  He was 25 when we met and had already gotten his PhD in math from MIT and was working as a professor at the University of Chicago, but he has never treated me as anything other than an intellectual equal. And we've remained close throughout big changes in our lives. I met Sarah and moved to New York and then eventually Indianapolis and became a dad. I fell in love with a historian and they got married and moved to the suburbs of Chicago and had two beautiful kids. Everything was good and normal, and then one day Daniel called me with the worst idea I had ever heard in my entire life, which was that he wanted to leave his very good job at the University of Chicago and run for a seat in the Illinois State House of Representatives. This seemed like a bad idea to me first because Daniel is, like, nerdy. In my mind politicians were slick and wore tailored suits, and I don't know that Daniel owned a suit. Sarah and I were in the audience for Daniel's campaign announcement and what may have been his first ever campaign speech, and while his eloquence and intelligence were obvious, as I was driving home I couldn't help but think that Daniel, how do I phrase this gently, might eventually find his way back to abstract mathematics. And indeed, while Daniel's 2008 race for state rep was agonizingly close, he lost. But he ran again in 2010 and won, and then in 2012 he became a state senator. And over the last eight years Daniel has become a brilliant politician and an extraordinarily effective legislator in a state where it's famously hard to get anything done. He's built bipartisan support on everything from improving retirement benefits to ending exploitative student loan practices. And now he is running for governor of Illinois, not just running, in fact, he has a very good chance of winning the Democratic primary on March 20th, even though his two opponents are a billionaire who has spent tens of millions of dollars on advertising and a literal Kennedy. Those are the kinds of people we tend to think of as likely politicians, heirs to famous families, billionaires who can buy all the TV ads they want. I don't generally think of politicians as people, like in my mind they're somewhere between superheroes and supervillains, larger than life characters with tremendous powers battling it out while the rest of us get our houses stomped on by their giant robot suits. But imagining electoral politics that way can become a kind of self-fulfilling prophecy, like the main reason I didn't think Daniel should run for office all those years ago was because he didn't seem to me like the kind of person who would succeed at it. But if people like Daniel don't run for office or we don't elect them, then we end up with the comic book version of electoral politics. Obviously we don't need Lex Luthor running our governments, but I also don't think we need Superman. We need capable people who know how to govern, who can build consensus, who can listen well, and who can hold competing ideas in their minds. When your friend runs for governor you realize that politicians are people, even the billionaires, even the Kennedys. So the question becomes not who looks or acts the part or who has the money or whatever else, the question becomes which of these people, no more or less human than I, do I think would be best at this job? And if I'd thought of politics that way I would have understood from the beginning that Daniel would make a successful politician. And for me that is real cause for optimism. I am so proud of Daniel and really excited to support him. He and I are going to do a Facebook live event this Thursday at 1pm Eastern time, so I'll ask him some questions. You can ask some too, more info in the doobly-doo below. And if you live in Illinois, vote. Also if you don't live in Illinois, vote. Hank, I will see you on Friday.


All right, give another 30 seconds or so that we'll get started three past the hour. All right, three past the hour. Why don't we go ahead and get started? Let's see, community time. Any topics from the community that people want to bring up? All right, not hearing any. No update on SDK. I believe I'll call Skiddle for next week. So maybe next week, we'll have something to mention. Kukani recap, two things. One is during the service working group session, most of it was actually a burden of a feather kind of thing where it basically tried to engage the audience to get their feedback on things like, why are they using serverless? Why are they not using serverless? What are their pain points or stuff like that? Not going to go through this document here, but I did want to point out this document to you guys if you're interested in hearing or reading the notes on the session itself in terms of the feedback we got from people. The link is right here in the agenda doc. So you guys can take a look at that later if you want. However, I did want to leave an opportunity for people who were at Kukani to mention something in general that they thought might be of interest to the group. So does anybody have anything from Kukani that they want to mention that might be of interest? Okay, I'm not hearing anybody. Kukani China, slides are not available yet. As soon as those are ready, Catholic is available to put the group to review. The one thing I do want to mention is that I do want, if possible, for you guys to keep your end points up for the demo because I am planning on showcasing the demo during our session, or one of the two sessions there. So please keep your end points up so we can run the demo there. I'd appreciate that. Next week on Tuesday, I believe, we'll have the TOC call, which I will ask about the criteria for going to incubator. Just a reminder for everybody that that's coming up. And I will ask this question about whether there's a requirement for us to be beta or a certain version number. I think the interest, no, but I will confirm that with the group. All right, onto PRs. Is there any of the topic that people want to bring up before we get the PRs? All right, in that case, Gem, you are up first. This is about the easy one. You want to talk to this one? Yeah, we like easy, low-hanging fruit stuff. So I just happened to look at the JSON schema and it just had the subject admitted. I guess it was, you know, we added subject as a context property and just missed it. So I've added it in. Right, the same fell straight forward. Anybody have any questions or comments on this? I do have some clients on the overall structure of the schema. So it's a bit funky to me, but I understand what it's doing. Well, obviously you can open up another issue or PR if you want to change that. That's true. That's true. All right. Okay, any questions, comments on this one? Any objections? All right, I have a question. So this is spec.json. Does it need to be added to anything else or is this the only place where it was left out? I'd correct my wrong, Gemma. I believe this is my place where it was left out. I think so. I just happened to spot it when I was looking at that schema file. Okay. I think this might actually be the only schema type of document we have in the repo at all, I believe. There is a proto-buff one, but proto-buff is slightly different form. So I did check that and there's no change required to that one. So does this one actually have a schema to it? Yeah, it does. There's a separate schema file. There's a spec.proto or something in the repo. Somewhere. Oh, there it is. Yeah. It's not simple. I was gonna say it's pretty small. Yeah. Okay, cool. Let's see, going backwards. Any objection to approving this one then? Nope. All right, thank you, Rachel. Anybody else? All right, not hearing any objection. We can approve. Thank you, Gemma, for that. All right. Now, Clemens is not on the call, but I did want to at least bring this one up for people's attention. Let's see. So basically, if I have this correct, oops, let me sort of hide the comments here one second. So basically, this PR is trying to address the problem that, I can't remember who it was from Google. Might have been Alan mentioned that we're putting quotes around our HTTP headers or the spec requires us to put quotes around HTTP headers even though we don't really want to do that. And what I believe Clemens is proposing here is to basically at the spec level, well, let me phrase it like, what he wants to do is define a string encoding format for all of our different types and then say for things like HTTP, use the string encoding for those particular types and then the receiver, when if they understand the type with that particular attribute, it can convert it into the appropriate type. So for example, a timestamp type. For example, but for any types that people do not understand, they'll just keep it as a string and then pass it along as appropriate. That I think is the basic idea here. I wanted to, like I said, I want to put this out there for people to start commenting on it and then think about it. Obviously Clemens will do more speaking of it next week when he's on the call, but I wanted to get people's initial reaction to it. In particular, Scott, I was wondering if you had a chance to look at this one and think about it. You too, Jem, I'll pick on you next. Sorry. So Scott, have you had a chance to think about this one? Cause I know this was a topic that was near and dear to your heart. That's what I do today. Okay, so I take it that means you're in favor of this direction? Yeah. Okay. Jem, what about you? Cause I know you at one point indicated you would really prefer to have the type as part of the encoding itself. Yeah, because the way I read this when I quickly went through it is basically saying it's up to the SDKs to understand the types of the underlying attributes. Yeah, so, or at least the transport spec has to understand the type system so that it can move stuff backwards and forwards based on the name of the attribute rather than explicitly in the type in the protocol itself. So I mean, I don't quite understand how this works for extensions, for instance. I guess I need to read it a bit more. I don't understand how an intermediary can forward an extension without losing its type information. And I also don't understand how an intermediary could forward maybe a new rev of the spec without losing its type information. So that's, I need to read it more deeply. Yeah, so Scott, correct me if I get this wrong here, but I believe that extension for the unknown extensions are basically just passed around to strings. So there is no type information whatsoever. If you know about the type of the extension, then obviously it's just like any other attribute. You can convert it as part of the SDK or application code. But in general, unknown extensions are just strings is the short answer. I also think it's a non-goal to be able to convert between clot event versions of being version away. Yeah, I don't know whether that's a goal or not. I don't remember staying, being stated as a goal. So yeah. But I definitely recommend people look at this because I do think it feels like it could have big ramifications for us, even though I do agree with the direction and I think it's the right way to go. I think it's not that big of a code change. Philosophically, it is a bit of a different way to view things. And I want people to be very comfortable with this. So I'm not gonna like ask for a vote or anything today, but I do want people to be prepared for potentially voting on it next week. Because I know that I've heard from more than one group of people that they would like to try to move the spec as close as we can to 1.0 sooner rather than later. And this is one of the biggest items that's lingering for us to resolve. So I'm gonna try to push for a vote next week if people are okay with that. Anyway, Tapini, your hands up. Yeah, I thought it was, it is an interesting point that this will affect how extensions can evolve and also how conflicting extensions will see each other. Earlier, if you would have had a conflict in the type, you would have noticed in the type. Now, if you have a conflict, it will just be a bad form of string in the next, in the next extension version, or if you have conflicting extensions that expect different types, which have special meaning, but are encoded as a string without any identifiers. Can you elaborate on how you thought other proposals addressed that? Cause I'm not sure they did, right? Cause you have two people to find. I don't think, nothing has particularly solved that, but this just alters how that works now without it being. Because this will define how that would work. They would just be strings that have special meaning, but are malformed for each other if they expect different types. It's just a side effect that came to my head. Okay, gotcha. Okay, anybody else? Oh, sorry, and? No, go ahead, Europe. I think that's actually a benefit because in the previous case, you'd have an int trying to be passed in as a string and that would just run time exception. Now we have a chance to actually expect the string because you know the type ahead of time, no matter what the actual type is. That is actually true, and a good point. Thank you, Scott. Anybody else have any questions or comments on this one? Or any points for discussion today? Okay, you guys are awfully quiet. Okay, in that case, please take your time to look this over because if there are no comments or concerns before next week's call, I will ask, if you're okay with approving it. So if you do have concerns, please get them out there sooner rather than later so that the clients could try to address them. And Scott, correct me if I'm wrong, but if we do approve that one, that resolves your PR, correct? Does it supersede the idea of encoding the bytes of JSON inside the headers? Like it's the first step, there's another augmentation at the right to the HTTP binary specification to say that we, unless it does, okay, it does. That's what I'm trying to figure out, right? Here's the HTTP binding, here's the examples. Yeah, canonical string. This would make my job a lot more clear. Okay, yeah, and to be clear, I believe in this one, Clemens hasn't had a chance to respond to my message, but I believe the interesting thing is if you have an extension that's technically defined as a map, it will appear this entire JSON looking thing will actually just appear as a string. It will not actually come across as a JSON object unless the receiver happens to know what's a map and then can convert it for you. But if it's an unknown extension, it will just get passed along as a string. That's true today. It's not true for maps because they have a different encoding. I forgot nevermind, yeah, you're right. I forgot we do maps special. I don't like that, but yeah, I forgot. So technically, you're right. There should be CE mod extension dash fruit, right? Anyway. That's right. I think that's what we say today. Yeah, I forgot about that. Additionally, today, if those are supposed to be string quoted to make it a string, you'd have to parse it as a map rather than a string. Yeah, okay, I'll fix my comment. All right, anything else on this PR? Okay, as I said, please take a look at that when you get a chance. And let's see, moving forward. This PR has been out there for a little while. I did make some very minor changes this morning just to do a little bit better alignment in the difference between producer versus source. I don't think it fundamentally changed what's in here. I don't know if everybody has a chance to read it yet, but I'll give you guys just about 30 seconds or so to read through this, see what you guys think. Okay, any questions on this? Does this seem consistent with the direction we've been going, especially with our recent discussion around the uniqueness aspect between source and ID and stuff like that? I don't know if it's worth specifying when we say from a single event source, meaning the same source string. There's sort of a conflation of the idea of an event source and then the source attribute. Yeah, I guess when I wrote this up, I was assuming that when I say things like one event source or a single event source, it means the same source string. I guess I could be a little more explicit if you think that'd be clear. I mean, I feel like it might be good to be clear that that string is an identity space for event sources and there isn't any other identity space. So maybe that's part of the source attribute, but historically that's been a little bit loose about what the source attribute looks like and how that maps on to systems that produce events. Yeah, so I do actually call it out right here, but I guess what I could do is take this part of the sentence and move it up to the top and make it clear that I'm talking about the same event source I mean the same attribute source attribute value. I can move that sentence up higher and make it clear that it applies to all cases, not just this one paragraph. Okay, I can do that. Anything else? Is it source or required field? I believe so, let me just double check. Yes, it is. Okay, thank you Scott, yes. I think it's spec ID or spec version number, source ID and type of the four required fields. Does that change any of this for you, Jim? No, no, I just wanted to make sure. Okay. Okay, so any other questions or concerns about this one? Okay, let me ask this question. I do want to make the edit that Evan was suggesting so I think it probably is a good one, but I believe that the relatively minor change basically taking this type of stuff that I've highlighted and basically moving it a little bit higher to make it clear. I think that the relatively minor wordsmithing change, would you guys be okay with assuming we approve it now with conditionally approving this, with that change and then I'll make the change and wait for one or two LGTMs offline and then merge it, would you guys be okay with that direction so I don't have to wait a whole nother week for relatively minor wording change? Yeah, that seems fine to me. Okay, thank you, Rachel. Okay, let me ask you the first question. Any objection to approving this with that wording change as suggested by Evan? Basically taking this part here and moving it up higher. Okay, and any objection then to doing sort of a deferred merge based upon the edit? Okay, cool, thank you guys. Whoops, what did I just do? Okay, hold on a minute. Okay, I'll take care of that, thank you Evan. All right, technically this is the last PR I can't be reviewed today, everything else has some issues with it. So Scott, I wanna pick on you for a sec. So I added this text here basically to talk about the role of event producers that are separate from the event sources, meaning you have this entity whose job it is is to create the cloud event on behalf of the source. And I basically go into some ramblings about how they should go about doing that and how they're not necessarily there to represent themselves, they're there to represent the event source, it's just the source wasn't producing the cloud event. Now Scott, you had originally had some concerns about this and I was wondering whether those concerns are still applicable or you're still worried about them or based upon the recent discussions around source and type and stuff, whether those concerns that you had go away. I believe they're still there, you still are stomping the namespace of the original producer of the event. So can you point me to where in here I actually say that? I haven't read this a new text yet. Okay, okay, well I don't wanna rush this since Scott you think you may have some concerns with it. So let me just put this out there. Please, when you get a chance, please look at this and in particular if you're writing a, for lack of a better phrase, an adapter, something that will take an event from an event source and convert it to a cloud event, please make sure that there's no text in here that you think would make it so you're now violating something or not adhering to the guidance in here or if you just think I'm just way off base, let me know. But I do think that we do need some better clarity because I think there are some people who have different expectations for what event producers do, like for example, whether they put data in there representing themselves or whether they put data in there just that represents the event source. And I think understanding when it's appropriate to do each one of those, because I do think if there are times when it is valid to do each one of those, but understanding when those times are valid would be very useful and I do talk about that in there but it is a little bit of a ramble. So please take a look at when you get a chance. But based upon what you guys may have looked at already, does anybody have any questions or comments that they wanna bring up now for discussion? Otherwise, we'll just do it offline. Okay, you guys are awfully quiet. Okay, so please review that when you get a chance. Technically, that's it for open PRs that can actually be resolved today. I'm trying to think of anything in here that we can discuss. Okay, classes are on the call, so I thought I was gonna ask you about this one. Okay, before we actually adjourn, since there's anything else on the agenda, let me do one other thing here, hold on a minute. So these are the only PRs that I've actually tagged as 0.3, I believe that these last two technically should be closed because they were, these are the ones that Kristoff proposed and we ended up going with Clemens size constraint PR instead. So I think once we resolve Clemens PR, all three of these will go away. So really the only PRs we have open for 0.3 is the type system one that we're talking about earlier. If you guys think there are other things that we need to get in for 0.3, please let me know because otherwise I'm gonna assume that once these are resolved, we will be able to go forward with a vote on 0.3 and get that next release out there, okay? I still have huge questions about how to actually implement batching. Okay. I've wrote an issue for it and. But is that a concern for 0.3 or just a general question? Well, batching was added for 0.3 and so the release of 0.3 then forces everyone to support batching if they want. Well, I guess it's optional, but I have no idea how to support it. Well, tell you what, why don't we... Okay, so do me a favor, since we have a little bit of time right now. I think I might agree with Evan that it may not necessarily be a blocker for 0.3, but I think we can look at that offline and decide that. Obviously, I think it's a requirement for 0.0, obviously. But can you take some time right now to elaborate on where your concerns are around batching? I mean, it's written here. I don't know what to do if I'm delivering something to some other entity in a... Like, there needs to be more guidance on how delivery happens for the batched thing and what processing should be and what happens when delivery of the middle event fails and how do you upstream that response? It's a... There's just not a lot of guidance on how to actually deal with batching of requests. Sounds like a particular in the failure case where you wanna act, say, events one and three, but not event two that... Yeah, exactly. Or, you know, one and two are okay, but three caused a failure. Do you knack all of them or I don't know how to do that stuff? I'm just trying to refresh my memory on what we say in batch mode here for HTTP at least. Does this thing talk about how to handle failures or responses at all? I mean, it's probably more interesting to look at the definition of what batch mode is and not the bindings for it. Because the bindings are pretty clear. It's the operation that I have a question about. Well, the spec doesn't talk about batching at all, does it? I thought that was just an HTTP semantic. Yeah, I don't see anything about batching in the spec. Let me see if the primer mentioned it. Yeah, so we basically say it's up to the transport to define it. So are you looking for something within the main spec itself, Scott? Yeah, I think because if you're transport agnostic, what happens when some middleware batches HTTP requests and then goes and tries to enqueue that onto an AMQ, PQ, but it encounters a problem with the middle event. Like what should that thing do? Can you elaborate on why you don't think that'd be a transport specific issue? Well, it's a cloud event issue, right? Pretend you're middleware and you receive a batch request over HTTP and your job is to forward it onto some other thing that doesn't support batching. What is the exact operations you're supposed to do? Let's say the negotiation, let's stay in HTTP, you get a batch request and then you're supposed to deliver it to a non-batched client. And so you deliver one, two, three and the third one gets an error. Do you knack or act the upstream request, it's batched.  It's interesting because if I remember correctly, the only thing in our specs which talk about error codes and performance is the web-book spec. Nothing, everything else is sort of very agnostic on transport because I had a similar question, what does this mean to the SDKs? Do they have to support batching as well? I understand the spirit of what it was written by, I completely get the problem of what an intermediary is meant to do when presented with one of those things. What's the expectation?  Yeah, can you link that, the document that you just brought a while ago where there was an example of two put batch requests? It's an HTTP binding spec. Oh, okay. Thanks. I assume you meant this one, right? Yes. Actually, my larger question here was, if we ever want to get batched in the spec, then can we make assumptions saying that the spec version for the entire batch is the same and so it's better to kind of have this metadata object and then the batch events like a more structured way? Yeah, I think my assumption is always it's the same version of our, although I'm not sure we explicitly say that. Yeah, that is right here. So it makes it a little bit easier. So let me ask you this question though, Scott. Do you have an idea for the direction you would like us to go? Because if you say yes, I'm gonna ask for a PR. Yeah, I don't because I don't have a ton of experience in batch processing. I don't know what the standard is that people actually would expect. Okay. Go ahead. So when we did it at massive scale, we kind of just had our own implementation like it wasn't specific to a general thing because it was highly context dependent. So just out of curiosity, in some of the scenarios that Scott has mentioned, how did you deal with those? So for example, if there are three different events batched up and the middle one fails in some way, how do you deal with that? Do you have three different responses in the middle one that indicates some sort of failure or is it only the middle one we give a response? No, so, yeah, the middle one. Oh man. Okay, yeah. So the response would include that success and failure and the ordinals of the array which failed. Got it, okay. I think this has to be worked into the webhook spec somewhere because that's the only thing that talks about behavior. And actually, one might argue that that should also in the options call say, well, I don't support batching so don't bother trying to send me something with a batch. It's probably the other direction. I do support batching rather than... Sure, yeah.  Okay, because I'm getting a sense that if nothing else, even if we don't change any of the specs, something might be useful for the primer because if Scott, you had some uncertainty around this, I'm sure other people will as well. So we need to think about what we can write. Yeah, I mean, try to implement it and then you'll discover some interesting corner cases. Yeah. So, but I'm trying to figure out the best way to move forward here because what I really wanna say is, what I really wanna do is ask for a volunteer to put together a strong man proposal of a direction and see whether people agree with that proposed direction. So for example, Scott, what would you have liked to have seen that would have made your life easier as you implemented this? Is it guidance that says how to handle responses and errors? Is that enough to have, but have been enough to satisfy your issue? Potentially what Jude's put in the chat, it becomes very difficult because HTTP allows for responses and batching. So you need to accommodate for new events that come as a result of the batch, but also some method of knowing that this ID was act in the batch that you sent. It's something like that would help, I think, but it's really complicated. Well, what's interesting, and I feel like my inner Clemens being channeled here is events are basically one-way messages, right?  That's not true. Cloud event spec says that if the transport allows for it, the cloud event can be bi-directional. Well, yes, you can send an event to both directions, but what I was thinking more along the lines of is, when you send an event to a receiver, we don't have to define an act, right? I mean, because you could recite back with a 202, which means nothing other than I got the message, right? And there's no confirmation that it's been processed correctly. And we don't tell you how to send back any message or any kind of indication that it was processed correctly. So if you take that to the next level and say, okay, well, if we're not gonna have any kind of knack defined for single events, why would we bother doing it for batched? And I think that's my point, yeah. It's only the cloud event, the webhook spec that talks about response codes. So that would be my argument as to where that batch handling should go. Yeah, so I guess my question for you, Scott, is if you think of this as asynchronous processing, why do you wanna send a response at all? Because the spec allows? Well, no, the spec allows for you to send a cloud event in a response flow, but it's not necessarily a response message, right? You, no, no, the request allows for a response, an event response. And we need to be pointed at the same thing. Can you point me to the document there? Talks about what you're referring to? Right, this binding spec for HTTP says that the bindings apply for both inbound and outbound responses. So you can infer that that means that if you send a cloud event, it may respond with a cloud event. Well, hold on a minute. I know what you're talking about, I just can't seem to find it, hold on. Here we go, talk about something like this, right? I mean, responses is referenced a couple times in this document. Yeah, I guess that maybe we need Clemens on here since he was the main author here, but I interpreted sentences like this to say that yes, cloud events can be transferred over HTTP responses, but that's not quite, excuse me, the same thing as saying that an event that we are defining cloud events as responses to cloud events. So for example, the request could have been, do you have any events for me? And it's not necessarily a cloud event on the request side. It's more like a pull request. But the cloud event itself could flow or raise your response flow. I don't think you can make that assumption on, like if you're writing in an SDK, for example, potentially any request can respond with a cloud event, even delivering a cloud event. No, I agree, it could. My point is, we don't draw any relationship between the two, the fact that... But if you implement that and you try to support batching, you get real confused on what to do. So let me ask you this. What do you think the specs say about non-batching message flows?  What's supposed to flow over the response? It's up to that implementation. Right. So why would batching be any different? The cloud event spec says that you can respond with stuff or not stuff. At some point, you actually have to help people understand what that error code, if it's in the webhook spec or what, you are delivered a batched request and you respond back with 400. What does that mean? I guess my question is, what does it mean in a single case? Yeah, what does it mean that you probably shouldn't knack whatever upstream thing or maybe re-deliver it depends on your implementation. But it's pretty clear that that 400 applies to the request that was delivered. The cloud event was sent to some hook. They have responded with 400. There's a one-to-one relationship there, but when you send a batched request, you don't understand. Yeah. Okay, like I said, I'm just trying to figure out the next steps here. So Topini, your hands up. Yeah, just kind of tangential to what you were talking about just now about Jude Pereira brings up a good point that responding with JSON arrays is not a good idea because some browsers don't support it. So there should be some kind of a envelope anyway to the batches. Likely better, the stream would have been better, the non-square bracket enclosed stream of JSON objects. So not batched, but stream. So Scott, are you basically looking for something in one of our docs that says, when you're doing batching, here's what the response message needs to look like so that you know the responses of each individual in essence request. Jim, your hands up. I understand where Scott's coming from, I really do, but I mean, in my mind, I'm trying to separate this spec from the transport specs and none of our specs talk about acknowledgments of publishing or anything like that. That I've read, that seems to be very much left to an SDK writer as to how he wants to, he or she, sorry, wants to represent that. Yeah, I think that's where I'm struggling with this as well. Because it seems to me that if I was writing an SDK for an HTTP transport, I could choose to batch stuff up and send it in one operation. I could choose to do it asynchronously or synchronously or whatever. I mean, I don't think we've placed the specs, don't put any commentary around an upstream person knowing whether that thing's been accepted by anybody. Except, and I'll come back to the web hook spec, which is the only other endpoint that has that sort of behavior. Maybe that's right or wrong. We don't have anything similar for a distant AMQP endpoint and delivery confirmations from there. So I understand a problem, but it's not unique to HTTP, I don't think. Yeah, part of me is also wondering whether this is, I'm trying to struggle with the final right words, whether this is not necessarily our problem in the sense that if you have two systems today, they're trying to exchange the events, especially in the binary format, right? Where cloud events is meant to just be extra sprinkling of metadata. It's not meant to be a complete reformat of stuff. So if you have two systems that are talking about another and they're transferring events back and forth, we'll ask them extra metadata to those events and that's great, everything works. But the many are talking about batching, if the current mechanism that they're using to transfer those events doesn't already support batching, I don't think they're gonna add it because of us. So that means to me that if they're gonna do batching, they would have already supported it, which means that they would have already solved this problem themselves. And the fact that there's now extra metadata in there with the cloud event attributes is almost irrelevant or it doesn't impact this problem space. Does that make any sense? Except we define explicitly how to batch structured cloud events on HTTP, but not how to process them. It's definitely true. Maybe we need a job there. Yeah, that is true. Okay, well tell you what, I don't think we're gonna necessarily solve it here, but I think a lot of interesting points that were brought up, so maybe what we should do is try to force the discussion in this issue that's got opened. And who knows? Maybe the net result would be we've removed batching and say if you wanna do it fine, but use whatever batching mechanism you would have used normally even if you weren't using cloud events. But. I wanna keep it in. I think it's there for a reason. I think there's an efficiency play there. Does that mean everybody has to support it? I don't think so. Yeah, but if nothing else, I think to address Scott's concern, we should at least say what to do for responses slash errors. And maybe the answer is we're gonna say nothing, but then we should explicitly say some place where we're not gonna touch that subject. I just want something in, I just want people who are reading our spec and primer to know whether we purposely chose not to work on something or we just forgot. And I don't want them to think we forgot. Okay, I'm willing to take a look at the web prospect and see if I can work something into that because that's your HTBN point behavior definition here. Okay, that'd be great. Thank you, Jim. I appreciate that. Okay, let's see, where were we? Oh yeah, so going back, please look at the list of 0.3 PRs. I believe that they're a small list. If you think I missed it, let me know. Other than that, I think we're at the end of the agenda. You guys just have lots of homework to do in terms of reviewing stuff that's out there. So please, when you get a chance to review those, in particular, Clemens PRs are really, really big one. So please look at that. I think that's it. Are there any other topics people would like to bring up for today's call? All right, in that case, one last little bit of work. Mehmet, are you there? Mehmet? Is there anybody else I missed for attendance? Yes, I am. Oh, Mehmet, gotcha, I knew you were there. Okay, anybody else that I missed for attendance? All right, in that case, we'll end early today. Thank you guys very much. And we'll talk again next week. Bye. Okay, bye, everybody. Bye. Bye, bye. Bye. Bye. Bye, thanks, Doug.