I know I was gonna say I don't recognize that name. Yeah, I've been I've been really busy. So yeah, I think everybody's everybody's been real busy recently kind of sucks. Hey, Jesse. Good morning. How are you? Good. How you doing? Good. And David morning. Simon either. Hi. Yeah. Hello. Yo, tell me. Hamid, you there? Here. Excellent. Hello. So after last week's call, so I made some comment to me about how my microphone was really loud or there was a lot of static or something like that. Is everything okay right now or do I need to get a different headset? I think you sound great personally. But that's just me. Yeah, you sound great to me too. Okay, just want to double check. Thank you. Yeah, okay. I was joined. How are you there? Yep. Hello. Hello. And Lucas. Hey. Hello. Hey there. Hi, Mark. Hello. Hi, Daniela. Daniela, you there? I'm a teamer. Here. Hi, Doug. Hello. Daniela's hiding. Hi, Daniel. Hello. You guys are really nice and early. I like that. Hey, Lance. Hello. So, Lance, I did ping Grant. I don't think I actually did it till yesterday or maybe the day before camera for sure. To remind him that he agreed to sort of talk to the commit tagging stuff or whatever you guys call it. If for some reason he doesn't show up, do you think you could talk to that to give a quick overview of how it all works and what we're supposed to do? Or would you prefer to maybe wait till next week since I'm catching you off guard? I can do that. Okay. Thank you. I appreciate that. Sure. Christoph. Hi. Hello. Daniela, are you there yet? Yes. There you go. All right. Thank you. Where are you? There you are. All right. Just a couple more minutes and we'll get started. Howdy, John. Hello. So I'm getting the sense that you're trying to take the place of Clemens and be like the troublemaker in the group or something like that. Is that the way this works? Is that why he's not showing up? We can't have two of you active at the same time. I don't have to try to be a troublemaker. It just kind of happens normally. I understand. Okay. Let's see. Manuel, are you there? Manuel. Hi. Hello. And Lou. Hi. Hello. All right. Let's see. I think I got everybody so far. Slinky. Howdy. All right. One more minute and we'll get started. All right. Three after. Let's do this thing. Okay. We got 20 people. All right. AI is Clemens. Not here. Okay. Community time. Anything from the community people want to bring up? That's not on the agenda. Me? Anybody? Yeah. Very quick. As you already know, I'm working on the implementation for the special language and I'm going to extract from it a kind of TCK. So adjacent contain several cases and the expected results. So what I was wondering is where should I place it? So should I place it like in the spec repo or where? The implementation itself, you mean? No. I'm talking about the TCK. So it will be a set of test cases in a defined format that each SDK or each implementation can consume and check if it's compliant or not. So I can show you an example of what I have in mind. Yeah. Let me go ahead and stop sharing. There you go. You should be sure. No, no, no, no. Yeah, I have to share. Okay, that's fine. Hold on a sec. Yeah. Okay. Open this link. Yeah, hold on. And I lost all my windows. There we go. Yeah, if you're going tests. Tests. Yeah. Anyone in particular? Choose whatever version you want. Okay. Choose the last one. Okay. And yeah, these are test cases. Each JSON is the test case. It contains the schema and then it contains the test with the expected results. I want to create something similar. So description of the test case, the expression, the input event, and then the test result. Interesting. That's kind of cool. Cool. My initial reaction is this sounds very similar to like that conformance work that I know Scott's trying to get going. So I'm wondering whether this would be best suited for a brand new repo. That way you can do more than or you can basically do whatever you wanted in there and have complete freedom. Does that make any sense or not? I don't know. The thing is that we are already, I don't know honestly if it fits the conformance repo. No, no, no. Not that repo. I'm going to create another repo just for this. That could be fine too. Well, the thing is that we already have, you know, the grammar, I already PR the grammar in the spec repo. Maybe we should have a folder like in the spec repo, which contains the spec and the spec, the grammar in the test cases. Like a bit of the, a bit of reorganization of the repo because in the repo we also have like, for each subspec we have everything in the root of the repo. So like for example, that for the subscription spec, we have everything in the root of the repo. I mean, it might, maybe, maybe it's time to, to order a bit of repo. Yeah, I know that that's been my to do this for a while. I actually was hoping to get to it this week, but I never did. So, okay. Yeah, tell you what, since creating a whole new repo does have some overhead associated with it, let's do this. Let's, let me go ahead and take the action item to create a PR to reorganize the repo. And then if it turns out a folder is, is annoying or too big or whatever, then we could look at splitting out into a separate repo later. Yeah, for me, a folder should be enough. Okay. Okay, so tell you what, let me, and I think it makes sense to have this, to fit inside the process that we use to merge things in this side of this repo. Because you know, it's good that people takes a look at the TCK and check if there's something that doesn't make sense. So yeah, I think it's better to give it here. Okay. Yep. All right. Cool. Anything else in the community if you want to bring up? Any other topics? All right. This week we do have the STK call after this one. Oh, yes. Hi, Scott. What's up? Hey, so I did some work on the conformance tool this week. And you can now send binary and structure events. And there's a raw dump mode. So go check out the CLI. It's, it's, it mostly works. Give it a try. Cool. Excellent. Yes, agreed. Woot. Can we grab a link to that within the meeting notes? Hopefully it's, everyone else probably knows exactly where it is. Hold on. Scott, yeah, can you paste the link in there and I'll copy into the meeting minutes? Easier for you to do that. No problem. Thank you. My screen. Okay. Oh, sorry. One more thing. I also released the 2.4.0 of the Golang SDK. There are a couple breaking changes. Sort of. We had to move some packages. They're technically not breaking. They are technically breaking. Okay. Well, we chose to not bump it to 3v3 because they're very specific niche usages. So if you're upset, I'm sorry if we can talk about it and we can work around it. So reach out if you're, you know, pitch forks. Yep. Okay. And Mark just mentioned that there's a new PowerShell SDK out there. So thank you, Mark. Anything you want to say about that, Mark? Well, you know, it's the initial input into, initial commit into the repo. So your mileage may vary, but the team's going to be updating it and should be useful for people that like to use PowerShell. Yep. All right. Cool. Anything else for community time? Oh, thank you, Scott. Hold on a second. I lost my window. Good performance. There you go. There's a link to it. Cool. All right. Moving forward. We do have an SDK call scheduled for this week. As of right now, I think there's nothing on the agenda. So please add an item if you want to discuss something. Otherwise, we'll cancel the call. Interop. We didn't really have much of a call last week. There has been a whole lot of progress. So let me just take this opportunity to nag people if you've promised that you, or if you said you were interested in participating. We did say we're going to start beginning of April. So please put up your endpoints in that document so people can start doing some testing. Let us know your status, which things may or may not work so we know what we can hit and what we can't. So just consider this being nagged appropriately. Anybody have any questions or comments on either of those things? All right. Moving forward. Just a reminder, I just signed up for two 45-minute sessions. There's the times. Please add your name here if you can join. Remy did upload his video. So I think it's probably too late to make any changes to it. But if you're interested in seeing the video or the slide, I did include the links here. So he's doing our cloud events session for us. And Timur, anything you want to mention from the workflow stuff? Just more SDK stuff. We added a .NET SDK and a TypeScript SDK, and both were community contributions. So that was really cool. And other than that, yeah, I picked our sessions at KubeCon very late. So we got us to end though. So yeah, we're going to work on that and make sure we have all the content from that ready. All right. Any questions? Oh, go ahead. Yeah. Does the .NET workflow SDK depend on the cloud events SDK, .NET SDK? Because if so, in fact, I was just writing an issue for the PowerShell SDK saying, okay, you're depending on the latest GA of the .NET SDK. That makes sense. But it would be really good if everyone could be ready for when we're ready to do the 2.0, which will have breaking changes for .NET. I hadn't been aware of so many other projects that were depending on the .NET cloud events SDK. I would love to avoid breaking people or at least make it as short a break as possible. So we should probably all get together. Yeah, definitely. I think right now that the workflow .NET SDK does not depend on the cloud events one, but that would be really nice actually to kind of combine them together in both the Java and the Go and .NET. And I will definitely try to join the SDK meetings for those discussions if that's okay with you guys. All right. Any other questions for a team around the workflow stuff? Okay. In that case, Grant, I noticed you joined. Thank you. So, Grant, do you want me to stop sharing or something you want me to click on? How do you want to do this education session? Yeah. Let's maybe go to the spec repo on GitHub. Let me just go here. Quick is easier to get there. Okay. Yeah. So one PR that we added in the master branch is to add a GitHub action that gives a green check mark if there's conventional commits. The goal of this is to, especially for folks that don't actively look at the spec every week and sort of you want an overview, it's to enforce or at least encourage folks to use conventional commits when they're writing their commits. And so if we go maybe to like fix some typos, maybe the first PR there. So and we go press the red X under the fix or we look at that, yeah, under the details. You can see that the linter has ran and the commit message is like not a conventional commit. It says the subject may not be empty and the type may not be empty. And so the fix here would be to prefix with a type like docs colon and fix a few typos. And so then when we get a lot of these commits in our spec, folks can just look at while they serve can ignore the the like doc changes that don't really affect anything. And then if there's a feature, it'll have the feet prefix. And then you can look over commits more easily that way. Okay, Slinky has his hand up. Slinky, you have a question? Yeah, to be honest, I don't I don't understand why we need this. For the very simple reason that our Git flow is we do PRs, Doug merged them. So at the end of the day is Doug that squashes the PR and types the actual commit message, commit title. So I think what we need is just to have Doug adjust any the automatic message generated by GitHub when squashing PRs and merging them. Yeah, so that sounds fine. So the overall goal is when a developer looks at the spec, maybe a lot of developers don't look at it every week or even every month, but they'd still like to understand what are the top changes in the repo. So maybe the process is just if there are significant spec changes, when Doug merges them, they're like under Doug changes the commit message to like a feet or a fix or docs, depending on what the changes. But let me so okay, I have a couple questions, but let's go back to the queue. So Jim, your hands up. Yeah, and I think my question was along probably the same lines are slinky because I tripped over this. What I found myself having to do is, you know, as I'm iterating on comments on the PRs, I'm having to do squashes every single time. And so I wasn't sure if is it just the first commit in the chain that some that this rule applies to or every single commit that goes through. And, you know, is there an expectation that either I then when we're ready, squash the whole thing and give it to Doug as a single item, or the maybe a slinky said that Doug does it at the time that he does the merge. Because I mean, I think it's, it's, it's sort of affecting the way that I tend to work iteratively. So if people put some comments in, I'll do a, you know, I'll do another tweak and a commit and a push to address those comments. So you sort of get this backlog of changes, which eventually you want to squash. Whereas I think this seems to think that every commit I do could be the final commit. Yes. Go ahead, Grant. Yes. Let's get point. I think maybe we want to change the commit lead just to run when on the master commit, it shouldn't affect anybody just developing and trying to create a PR. Or, or, well, I guess, I mean, at least the goal is to the only real changes the squash commit at the end. And that's really where we care about if this passes or not. Cool. Okay. So, so let me ask a question. If, because I actually had a similar thought process to what I think Lance was saying in the chat, which is, I thought we were doing this to auto generate, in other words, like release notes, kind of stuff, right, change law, whatever I call it, right. And we don't have that process defined in here. Or, so I was wondering one, whether Grant, you were planning on doing another PR to introduce that process, whether it's simply documenting it or whether it's adding additional tools or whatnot, so that we can automate that process. But then also, do we want this, this change log stuff or this, this, this conventional commit stuff to apply to every single PR or just PRs that we think are significant enough to warrant mentioned in the release notes? Okay. So for the two questions, yes. So one is, you know, first, in order to get, to be able to auto generate a change log, we need to start using conventional commits so that the change log has something to work with. But yeah, the, the eventual goal is, okay, sort of like, yeah, the JavaScript SDK, if we start using conventional commits, then we can just auto generate the change log. And yeah, a further PR would introduce the auto generated change log. Okay. But is the assumption that if we need this on all PRs or just the ones that are significant? I mean, all, if, if we merge and have all the changes, all the PRs to have a conventional commit that would make it easier for the tool. Okay. Because I'd like to get a sense from the group in terms of the process everybody wants to follow. Because if we want to, if we want to be consistent, then it seems like every PR should follow the same process. And while I don't necessarily mind doing extra work when I hit that, when I hit the merge button, I can do that if people want. It also makes me a little nervous that I would be the one editing or typing the title that appears in the release notes when I kind of feel like it should be the author who at least does it themselves.  But I, I'm not sure I should be the one that comes up with that as opposed to the author themselves, because there's a capacity to get it wrong. So it makes me a little nervous. So I just want to make sure we're clear on what a process we want to go as we go forward here or what process we want to do as we go forward here. So Daniel, your hands up. Yeah, a couple of things. So first of all, there are, there are tags for commits that are meant to be like not this is this is not significant for the changelog, I think. But I think my convention chore is is one of those that generally is just kind of ignored by the changelog generation tools. So if we want to be consistent about having every commit be conventional, we can just, you know, have a type of chore or something that's that is used for, you know, things that are not significant. To the other question about whether we want so kind of having the commit author being the, or the PR author driving the, I guess the text of the line in the changelog, I think that's the that was kind of the point of having a linter like this is to kind of cause or force the PR authors to participate in that process and to get in the habit of writing a conventional commit such that their understanding that this is, you know, this is going to go into the changelog. And so I should think about, you know, how this should appear and write the commit message accordingly. So I think that was kind of the point of it is a tool to kind of force us to think in those terms. So that said, if there are issues with like, well, I want to add more commits to my PR and they're not, you know, and now it's forcing me to change my workflow. I don't know if there might be ways to to convince to configure the linter in certain ways. I think by default, it might assume that every every commit needs to be, needs to be conventional. But if we're going to squash, maybe there's a way to to configure it to only check the first one, because I think if you have more than one commit, then by default, Git uses the the title of the PR rather than the commit messages itself as the default, or as a starting point for your your final squash commit name. So there might be ways to to configure it to to know that, hey, we're going to squash, let's let's optimize for that workflow. Okay, thank you. Slinky, you're up next. Let's go talk because I think he has the same proposal that I have. Okay, Scott. Hey, so I've, you know, based on every other project to work on, we use a convention where we we use a special tag block. And then Kubernetes has this release notes tool that goes and looks at every commit that landed in that, that timeframe, and then extracts that, that little block plus potentially labels that were applied to the PR.  So that seems to work. Maybe we would like to do that because it's a little easier for the both the the CI process that we use in GitHub and poor Doug to not have to rewrite commit messages on smashing because this is, so here's the text of what the commit conventional commits uses. So basically says it's Doug's job. You might want to comment on that. So, so this is correctly wrong here, Scott. I think then the, the requirement of the developer or the, the person who's submitting the PR is to make sure that they're, they have the proper release notes section in their comment, right? Yeah, that's right. I could maybe next week I could show a little demo and we have some some wrapper GitHub action tools that help you kind of like extract a markdown file based on two hashes. What are the people? Yeah. What are the people think? And, and, and I want to add that it's even simpler for you for users because if we have a template for the issues, we will enforce people to write the release notes. So it's even better because we kind of force the user to do that. Yeah, that's that's a great point. We can add a template that shows, you know, here's the section you fill in. He could even add a comment that doesn't get displayed in the PR description and kind of explain what this thing is. And then every time any PR gets opened, you go through that little template and you can fill out the release notes. Okay. Anybody else want to chime in there? Otherwise I'm going to mention a proposal then. Okay. So Scott, you asked or you volunteered to, to share that process with us on next week's call. So why don't we go ahead and do that? And I, and I agree with you, Daniela. Yes, we'll modify the contributing doc if we even have one or create one if necessary. But yeah, whatever process we come up with, we'll make sure we, we documented someplace. I definitely heard that. But so in the meantime, though, it sounds to me like we're agreeing that not necessarily every single PR is going to end up with a release notes type of thing. So technically for the PR is that we already agreed to merge that have this quote problem. If we don't think they're worthy enough to mention that in the release notes, I can just go to merge those and not worry about the bot complaining. However, if there is one that needs that we think should be in the release notes, what I want to do is make sure people understand what things should look like. So grant is I'm trying to figure out, is this a good example of what the commitment should look like? I mean, is this when I do a commit, I just put this in the first line and that's all that's needed to turn into a feature to turn into a chore versus a feature or something like that. Yeah, exactly. So you add a prefix of the type and optionally a scope. And so, as Daniel mentioned, chore ones will not be added to the change log. And so we can sort of ignore those. But the significant ones like the features or fixes can have those prefixes. Okay. So it is the first line of the commit message, not the title of the PR, correct? Yeah, for the current implementation. Yeah. Okay. Okay. Cool. Okay, so let's spend too much time on this. Why don't we go ahead and table this until next week and then Scott can talk about his proposal for a slightly different process. Is that sound fair? All right, cool. Yeah, sounds good. All right, cool. Thanks, Grant. Okay, so before we jump into the PRs, and I will merge this one now, Slinky, any other topics you want to bring up before we jump into PRs? Got a nice long list today. All right, let's go back to Slinky, because it is the Slinky show today.  All right, back to this one. I believe a couple of people asked for this one to be held off a little bit. I think I might have been one of them. Personally, I did do some thinking about this, but I haven't changed my nervousness about it. But I also don't want to say block it since we can always change it again later. So I'm okay with this going in for now. But what do other people think about this one? Anybody have any concerns, objections, questions? Daniela? Yeah, just commenting that last time we had this discussion about how database process this. I did a few experiments on SQL FIDO and basically Oracle SQL Server and the major ones, they throw an exception. But I feel like I think was my SQL and a few others, they basically returned no. And I know we did have this discussion on whether returning no was a valid option. So there are a few databases that do that. So it could be a better alternative than this one. Slinky, did you want to comment on that or not? To be honest, I strongly disagree with that thing now. It adds a whole more complicated set of problems that I'm trying to avoid as much as possible. So I'll be honest with you. And if we want to add no, it's not just about adding no for this specific problem. It's about adding no in the whole spec and language design, which is the same thing I explained for the error for ending errors. This is a consequence of how ending errors is defined in this language. And I'm very open to change it or modify it. But then I think if we want to do that, we need to bring up the discussion at a more iron level. So how do we end up erasing the language? Do anybody else want to chime in? Okay. I guess my only question is, I don't have an opinion on whether we should have no or not. But I do agree with you that if we do choose to have it, that's probably a very significant change more than just this one operation. So my question is, and maybe you can refresh our memory, is if we don't want to support null or nil, would the next best thing not to be, wouldn't the next best thing be to just make the return value of this zero, even though zero isn't technically null, it's closer than max and min int? That'd be my only question for you. Well, the reason why I choose plus infinite and minus infinite is just because it seemed more reasonable to me. But we can go back to zero and that's fine. At the end of the day, this still raises an error and a user will still eventually end of this error. So anybody else want to chime in? Okay. Like I said, I don't have a huge feeling on this. My gut is telling me zero might be more intuitive for people if we're going to return any number at all. That's why he's running through my mind. But I don't want it to be just one vote either way kind of thing. Okay. Daniela says, I prefer not to change it until we have a clear benefit of returning something different than zero. Eric seems a little, he's towards zero as well. So, Slinky, would you be okay if we held off a little on this until we get more feedback? Yeah, sure. It's not a crucial part of the language. Okay. Yeah, it's not a big problem for me. Okay, I appreciate that. Again, I opened this just because it seemed more reasonable to me. Yeah. Okay. If you want to continue, it's fine. Okay. Is there any objection then to not doing this at this time? Okay. Let's move on to the next one then. Clarify in semantics. I think this was there last time. Yeah. So this one, we had the discussion of whether order databases act on the typecasting when using the in. And I, in the conversation, I wrote my findings. I tried with my SQL and Oracle SQL, I think. And yeah, it should be fine this way. So this way is more like order sequence, let's say. But can you open the conversation? Because if I click correctly on this one, Oracle SQL behaves differently from my SQL. This one? Yeah. Yeah. Yeah, because Oracle SQL doesn't have the Boolean literal stormfalls. And in my SQL, the implicit typecasting is only valid for binaries, but not for numbers. Here, I may be doing some mistakes here to be honest. So at the end of the day, they are not really the same between Oracle SQL and my SQL. So I just chose to go with what seemed reasonable to me and for the user of my SQL, which is just course, always the types to the left argument type. So that's it. And that's what I wrote in the spec. Okay. Any questions or comments? Nothing? Okay. Any objection then to approving? Done. Easy. Okay. Cool. John, do you want to refresh our memories on this one? Yeah. So this is replacing a fairly brief couple of paragraphs with significantly more detail attempting to squash out any ambiguity and also hopefully make life a little simpler and more reliable. So it's encoding and decoding HTTP headers that are meant to represent cloud event attributes. And it's basically saying perform percent encoding on anything that's not ASCII or is a space or is percent for obvious reasons or is a double quote. And the reason for encoding spaces and double quotes is so that we don't then need to perform quoting as per RFC 7230. But SDKs still must perform decoding via RFC 7230 for compatibility with previous versions of this spec. So my hope is that it is compatible. And it looks like the comments so far have been encouraging on that front. No one said, oh, it fails in this respect. I've tweaked a couple of bits of wording. Have folks had a chance to look at it as much as they're likely to? All feedback welcome. Any comments? Speaking just for myself, I have not had a chance to review it yet, but I was kind of encouraged by some of the comments I saw go flying by. That as you said, it seemed like most people were not too concerned about breaking things. So that was nice. And I'm definitely, while I would obviously like to get this in partly so that I can get the C sharp implementation in, although if the noises are encouraging, I'm happy enough to merge the C sharp implementation in a sort of this looks like it'll go in. But I definitely don't want to rush this. Let's get it right rather than fast. Right. I'm inclined to ask for just one more week, but then put pressure on everybody myself included to say, hey, unless you have concrete issues with this, we're going to take a vote next week. And that means it's probably going to go in unless people have some concerns. That would be great from my perspective. So anybody want to chime in at this moment? Okay. So let's do that because this is a significant change. So we'll vote next week. Whoops. Okay. It's sort of in one of my topics. I note that the expand versioning suggestions is in too new to vote. But it was from just over a week ago. So we might want to. Yes, I apologize. I where are you John? halfway through the two new to so up a bit. Oh geez. There. Yeah, I apologize. I was really slacking on my job in terms of getting the agenda ready. So you should see what we're like for the ECMO C sharp standards. And normally I do this stuff no later than Tuesday. And just this week just got away from me. So hopefully after next week, my schedule will get a little more normal and I'll be able to get back to getting this thing's done timely. So I apologize. As I suspect, most of these are not too new. So to forget this, I'll just remove that. Okay. Let's go back to slinky then. Because we like hearing from slinky. You want to, did we talk about this one? I don't think we did talk about this one last week. I think we didn't. Let me hide the comments. You could talk to it. Yeah, it's so this is basically putting some constraints on how bad you can mess up your engine, your expression language engine. So I'm basically explaining that the overloading is allowed, but the but there is limit on how you can overload. There is a sentence that is not completed because it was a casting functions with the same anyway. And so he puts some constraints on overloading and on variadic functions. So I'm just being more explicit on how you can define custom functions. That's basically or on how the spec can define functions and how engine can allow to define custom functions. So that's it. Any questions? Okay. I think this one's been out there for at least a week. Okay. Any objection to approving them? Anybody want more time? All right. Not hearing either. Thank you, Slinky. Yeah. Let me let me remove line 202 before merging. Oh yeah. Okay. Hold on. Hold for one typo. Okay. Can do. And John, I think you might have briefly mentioned this one in a previous call. You want to refresh our memory? So the the history of this is someone asked in the C shop repo, how do we go about versioning cloud events? And this is a topic I'd been working on internally within Google. And obviously had strong opinions because I tend to. But it felt like something that deserved to be in the spec repo. So we created an issue here, discussed it about a month or so ago. And I came up with this proposal, which I hope reflects the conversation from then. Now, given that it's a month ago, I suspect that almost everyone has forgotten what we actually said. But basically, this, this suggests that the, the type should be used as a sort of normative way of saying, do not expect these two to be backwardly compatible because they are different versions. And you know, you can define a producer can perform their own use of semantic versioning or not. However, they want to do that. But one thing I would like to be checked within this is the part around the data schema attribute. So I have asserted without any particular evidence other than gut feeling and previous conversations, exactly this paragraph that you're looking at now around data schema attributes is expected to be informational. So I can see it being really useful for tools that let you inspect cloud events dynamically. But my guess is that most code that is consuming a cloud event won't use the data schema at all. It will expect things to be as they were defined when, when the code was written or compatible with that. So please shout if I have completely misunderstood the point of data schema. I don't think I've had any comments on this one at all yet. I could be wrong. Again, I'm not in this is even less of a hurry to, to get merged. If folks could take some time to have a look and see whether I've written complete nonsense or not, that'd be great. Okay, any questions or in particular comments on that paragraph that's highlighted or where the cursor is? Just let me be even more forceful with that question because that is something I've often wondered myself because I tend to agree with you, John. I tend to think that people tend to like what a phrase sort of statically create the code that they're expecting to come in and the idea of dynamically changing what you're going to get and analyzing the schema at runtime, I just, I don't know how often people actually do that. I always had a gut feel like you that they probably don't. It's a little more static than that. But I would love to know, does anybody on the call have the opposite opinion that there are lots of cases where no people actually do analyze the schema at runtime beyond a superficial schema checker thing? Do people actually use it for anything real? I can imagine some cloud events with particularly dynamic data where the cloud event provider, producer, doesn't really specify the schema themselves. They just pass on data from something else. So you could have 10 different events all with their own different data schema attribute, but that would be for a very particular kind of cloud event, I think. Anybody else want to chime in with their experience? Okay. Can speak up for a moment. I was going to speak up and then you made that little quibble about using the schema for validation purposes. And I've been writing Node for a while. Because of the untypeness, there's a whole lot of code that I don't have to write if I use the schema validator to basically say this message that I'm receiving meets exactly the requirements that I have for that data. And so I don't think I don't see the scheme as informational as part of my security apparatus and everything. I don't know. I did a comment. Okay. So John, that sounds like maybe this paragraph here might be then a little too loose or something. Because it doesn't take into account what Eric was just mentioning there, which is, well, they may not necessarily do anything like dynamically create objects on the fly because of it or anything like that. But people may use it for schema validation at runtime. So it isn't strictly development time thing. Yeah. I'm fine with it being used at execution time, although I would have expected if you're trying to validate that the data you've received is reasonable, validating that against what the event itself says is reasonable feels like it doesn't buy you very much. It's sort of, do you say that you're okay? You do? Oh, that's all right then. I'm being overly flippant. But I would expect it to be more likely to validate against a schema that you have previously, that you knew about at build time. But I could be really wrong. I would be, I would love to hear more in written comments that I can then try to inwardly digest if possible. Eric, do you have any comments on that? I'd love to hear your opinion on that. I agree. I haven't accounted for dynamic schemas. And this is the first I've heard of it. So I definitely really need to actually read it before I make any more comments. Okay. Let's see. Why don't we, since John, you said this was even less of a priority for you. Why don't we hold off one more week and push for it to maybe get reviewed or voted on next week? That'd be fab. Thank you. Okay. Are we okay with that? Okay. So let's do that. Push for vote next week. Please review. Cool. All right. Slinky, you're up yet again. Yeah. These ones are quite easy. So this is concat WS. So it's concatenation, but using a delimiter. It's the same as anti-sequel. Just like you guys, what is WS stand for? Oh, with... Don't ask me. I'm not the one who choose such a bad name. Okay. Interesting. Yeah. That's what I was wondering too, Daniel. I thought maybe white space, but it seems weird that you can actually put in the delimiter. So it's not just white space. Interesting. Okay. Anyway, any questions for Slinky on this one? Any objection to... When did this go in? It's not too new, is it? Yeah, eight days ago. Any objection then to approving? With separator. Thank you, Lou. That makes sense. Doi. We missed the obvious there. All right. Just to double-check. Anybody have a... Anybody have an issue with approving it? All right. There we go. Thank you, Slinky. This one. Okay. You want to talk to this one? Yeah. This one, I basically simplified the definition of the casting functions. Semanticality are the very same. I just made the definition a bit simpler. Okay. Let me just give everybody a sec just to quickly scan these. See if anything jumps out at you. Seems fairly straightforward. Okay. Anybody have any questions on this one? Well, there is one semantic change, which is now... Is bull returns true if you pass a bull as a value, and then when you pass an integer returns the identity. Bull, when you pass a bull returns the identity, string, when you pass a string returns the identity. So that's the semantic change. Okay. Any questions on that? You guys are still going on about the concat thing. Oh my gosh. So funny. Okay. Any objection then to approving this one? All right. Done. All right. Next. Moving right along. Wait. When was the hell does this one... This one's eight days ago as well. It's good. All right. You want to talk to this one? I changed substring to look like SQL. Simply. What was it before? We're starting at the... Yeah. Ending with length versus length versus index. Got it. Okay. Yeah. And then it's one indexed. Got it. Yeah. And to be honest, this the string built-in functions were very drafted. So I scanned them, scanned all of them and checked if they behave like other SQLs. Cool. That's why several PRs on this subject. Okay. Any questions on this one? Any objections to approving? And back to our favorite XML.  People were mocking things written in XML. So I pointed them to this PR. So, Gem. We're like a good mocking. I partly did this as a mental exercise, but there was an outstanding issue. So it does address that. Take it or leave it. I think that's what it is. I mean, this is... It shows a mechanism that you can express cloud events in XML format if you want to do so. Nobody's mandating that you have to do it. For all the XML isn't trendy. It's extremely well supported in just about every language ever. Exactly. I suspect it's actually far more useful than if we ended up with a YAML format or something like that. Cool kid stuff. Yeah. I was pleased to see this at which point I'll say I haven't reviewed it in depth, but I was pleased to see that it existed. Well, thanks, John. You're my new best friend. Well, you realize, of course, if we approve this, the next step has to be a soap binding. You're right.  No, no, no. No. Fine. Okay. Any questions off the bat? I mean, there's a little example, I think, at the end of this, which sort of will give you a glance into what the actual event structure would look like. Yeah, so that's what that's basically how you can think about it. I will admit, I've not written any XML stuff for about 10 years, but I do remember that it was much more efficient to be attribute heavy and support a more streaming style. So that's the model I went for. And I added batch support at the same time. Yes, I noticed that. I'll be honest, I have not had a chance to review this yet, so I'm probably going to ask for more time if you're okay with that. But one thing that comes out of me is, how can you do things like put VR instead of version or spec version to completely align with the attribute? Again, I think this is a constant battle I have. This needs to be humanly legible, but it's machine interpreted. So anywhere that I tend to try and be as efficient as I can, there's no need for verbosity there. So I'm all about bytes on the wire, essentially, especially when we're talking about XML, which is naturally a little bit verbose anyway. So I can show you if you want to see unverbosed, you should look at Swift messages or 6ML or something like that. Yeah, just the inordinate side of me likes consistency. That's the only reason I was thinking about that. So let me pick on some folks. Yeah, go ahead. Sorry, I was going to ask, is there a reason why VR is special for having its own XML element? So if you're stream processing, you need to get, in my mind, you need to get the version as early as you can, so you can then make assertions about the stuff that follows it. That was my only way of thinking. I mean, originally, this was also a way of enforcing the version to be present. I didn't go down the road that I did with the protobuf stuff of having all the required elements present, because it just looked a little bit messy. But having the version stuff there forces it. Oh, and having it as a sequence, so that has to be there. So obviously, you could say, well, the first atta has to be for the spec version, but that couldn't be enforced in the schema itself. Exactly. And depending what sort of XML generation process you're using, you couldn't always control the order which those elements are going to be emitted. Could you not have just made it an attribute on the cloud of anything? I would have thought this would be a version attribute on here. There you go. You see, man after my own heart, actually heavy. Yeah, I could do that. That's good feedback, Doug. Thanks. I'll make that change. My only feedback is at the utterly trivial level of there appear to be some extraneous blank lines in the schema. Oh my gosh. Yeah, okay. That's there for human readability. That's just me. That's my personal star, but we can rip those out. If that's all that's holding it back, John, I'm more than happy to rip it out. I will have a proper look next week. Okay. We're coming up on time, but Slinky, why don't you have the last word since your hands up? No, no. You said exactly what I wanted to say that you should have the version inside the cloud event. And to answer Slinky's comment, you would be surprised that I may already have a sort of rough support for it. Waiting for it. So exciting. Yeah. Okay. You can tell it's been a slow couple of weeks, can't you? Yeah. Okay, so minor changes. Oops. Okay, look to approve next week. Oh my gosh. It could be the fastest PR I've ever got approved. There you go. Okay, with that, we're technically almost out of time. I think I got everybody for the tenure list except for Klaus. Are you still there? Yes, I'm excellent. Could we do, could we, Doug, if we have a chance, could we look at the next one? Because it's really, really minor. And I think John was the guy who prompted me into it. Sure. Go for it. Here, let me hide the comments. Yeah. So just for reference for people, this is, for some reason, I had a mental brain fart and I didn't add batch support when we originally defined the prototype format. So this adds that. It's really simple construct, just a repeating set of events. John, does everything look okay to you? It does indeed. This one I have actually reviewed. I think even if I'm able to give approval, I think I probably did. Yeah. Basically, German, I had the same thought at roughly the same time and he was good enough to implement it instead of me doing so. Okay. So I think, Doug, you've made that comment. I can change that language. I mean, as I said, I was trying not to just blindly copy the language from the JSON format, but that is very similar language. Okay. Yeah. If we're inconsistently awkward, then that's fine. That would not hold up the PR. Then it bothers me that much. I'll open up a separate PR and try to dress both specs at the same time. Right. That would be a good, I think a good move. Okay. Because it is a bit of a struggle to read, but you understand the thrust of it. Yeah. Yeah. Are you hoping to vote right now?  Okay. Well, let me ask the question. Is there anybody who wants more time to review this? Any objection to approving? Even if you, well, I already asked if I want more time. Okay. I'm not hearing any objection. Especially since we have had somebody who knows this stuff like John, he's okay with it. I see no reason to wait. It's been seven days. So one last chance. Any objection? Okay. Cool. In that case, we are done. Thank you all. And last chance, did I miss anybody for the attendee list? All right. Cool. In that case, if you're not, if you're a non-SDK person, you're free to leave. Anybody have any topics for the SDK call? Otherwise, we will not have an SDK call. All right. Not hearing anything. We're then completely done for the day. Cool. Thank you all. We'll talk again next week. Good call. Thank you. Bye everybody. Bye. Bye. Bye.


This is a short introduction to decoyFS, a new file system developed at IBM Research for securing data at risk and preventing data theft and corruption attacks. To start, let's briefly talk about what motivated us to develop decoyFS. When we look at a commodity file system today, we see that they often show a single monolithic view of directories and files to all users and application processes also known as subjects. This means that file systems are easily exploitable by malicious subjects such as ransomware and other forms of malware. For example, they can encrypt and hold our data for ransom, modify or delete critical information and steal sensitive files. Notice that conventional file system protections like access control lists cannot fully prevent such attacks. To break this cycle, we realize that most genuine subjects only require access to directories, files and file types relevant to their work and do not need to know about all other files on the system. DecoyFS embraces this insight by transparently stacking multiple file system layers. These layers are called overlays and can be fully controlled in order to create customized views of the file system for every subject individually. DecoyFS offers three main controls when creating a customized view. First, it can hide files from being available to a subject. For example, it can only show the files required to accomplish a task for a given subject. Second, it can inject new files or replace or redact existing files with baits in order to lure subjects to interact with seemingly real files, all while maintaining a consistent view of the file system to a subject. And third, DecoyFS protects the base file system by intercepting white operations and redirecting them to its intermediate overlays. This allows DecoyFS to protect the base file system and resist data corruption and ransomware attacks. The controls of the DecoyFS overlays are informed by in-depth monitoring, analytics and security domain model along with policies. The overlays, which are maintained for every subject individually, offer customized views as well as a perfect blueprint from which to mine indicators of compromise and trigger alerts. Let's look at the decoy file system in action. This is a desktop environment using DecoyFS. In this demo, we show two different file browsers. The green file browser to the left is trusted, while the red file browser is untrusted. Notice that both browsers see the same file system structure, and up to this point, there are no apparent differences between them. So, a genuine user can open a sensitive file and inspect its contents normally. However, when an attacker attempts to open the same file, he's instead presented with different contents. Meanwhile, the file system records all the forensic marks left by the unauthorized file access in the overlay. Now, what would happen if a piece of real malware was executed on this machine? To answer this question, we will execute the Arribis ransomware. This ransomware infected thousands of websites hosted by a South Korean web hosting company in 2017 and resulted in over $1 million paid to recover data encrypted by the malware. When executed on the system protected by DecoyFS, the ransomware is presented with its isolated view of the file system. The ransomware encrypts all the relevant files it finds. While it appears to the malware that it was able to accomplish its mission, in reality, all modifications are confined to its very own view of the file system without affecting legitimate users, as we can see by looking at the green file browser to the left. DecoyFS was able to effectively deceive Arribis into disclosing its full behavior without posing any harm to the actual file system and user data.


Hello everyone, welcome back to another session in dentistry and more. Today's topic in conservative dentistry is pin retained amalgam restoration so usually Amalgam restoration we've been using the amalgam for many decades, but in recent time we have better products As restorative material because amalgam has many disadvantages. One is its color. It is not at all aesthetic and it is Requiring a minimum 1.5 mm thickness. So if it is less than 1.5 mm The strength will be marginally decreased. So it cannot be much recommended on class 2 cavities So if it is properly done on an ideal class 1 with proper 90 degree bud joint It may last or it will last for many years But if we are planning to do amalgam restoration on a weekly structure tooth or a grossly decayed tooth We need to give additional Retin T features So in that case one of the Feature is pin retained Amalgam restoration that is we are keeping pins within the restoration or within the dentine To provide the amalgam restoration more retention Because the tooth is in a compromised state because we are not able to provide proper walls So the retention provided by pin would be sufficient So that is what we are going to learn in today's session that is pin retained amalgam restoration The pin retained amalgam restoration is defined as any restoration requiring the placement of one or more pins in the dentine To provide adequate resistance and retention forms It is used whenever adequate resistance and retention form cannot be established with slots, locks, undercuts So this is the basic retin T features we give to the normal amalgam restoration So still it is not sufficient in those cases we can opt pins for the additional retention and resistance So it is nothing but placement of one or more pins to get the additional retention and resistance So it is commonly indicated for tooth with extensive carisofracture or it can also be used with cast restoration And the main advantages are the one thing is the conservation of tooth structure Then it saves time when compared to the cast restoration and it is economic And obviously it provides a better resistance and retention Whereas the disadvantages one is dental micro fracture or grazing So dental micro fracture grazing may happen because of the pressure which exerts by the pin to dentin And there will be micro leakage around the pin and it might decrease the strength of amalgam So there will be micro leakage and it might decrease the strength of amalgam And there can be chances of perforation of the pulp or external tooth surface So these are the disadvantages Now let us move on to the cavity preparation So the cavity preparation of these mutilated teeth through Excavation of carious dentin and removal of all undermined enamel So we need to keep the dentin floor must be sound and the rims of the preparation And the damaged area is then squared to resemble a shoulder finish line So we need to make it squared finish line Then the outline of the cavity is extend on to smooth and sound tooth structure Not on the undermined enamel Okay it should be on the sound tooth structure, the walls The cavity outline And we should make every effort to conserve the remaining tooth structure And there should be additional undercut can be given in the cavity walls So if this is a crucial cavity, so this is ideal Class 1 Okay So additional undercuts can be done in cavity walls Additional undercuts can be given So undercuts can be given Then the cavity depth is detected to determine the type of base should be used Now let us move on to the pins Okay So we have basically three types of pin The first one is cemented pin which is also known as mercilipins Which is larger than other pins and it uses sink first feed cement For the cementation It has got 3mm into the dentine and 2mm outside The second one is friction locked or tapping pins Which is smaller, which is actually retained by the resilience of dentine Because it has got friction There is no cement is placed here It has got the resilience of dentine is keeping it in its position So maybe it has increased retentive features and the cemented one But the problem is with the time when dentine relax There is chance of loosening of this pin So that is cemented and friction locked pins Now we have the self threaded pins It has got threads So threads in the pin So this is almost equal in dentine and outside there is 3mm and 3mm This is 2mm and 2mm It is self threaded pins It is available in different size It threads the threads which is present on the surface which engages the dentine It depends on the elasticity of the dentine Which is the most retentive one And there is less chance of corrosion But it create horizontal and vertical stress And it cause the dentinal crease lines Now we move to the TMS system There is ThreadMate system pins So we have pictures here Regular one It has got 0.031 inch diameter Then minimum It has got 0.024 diameter Then Minikin 0.019 inch diameter And Minuta which is 0.017 inch diameter So you can see the picture here So this TMS system available in double shear That is 2 pins in 1 And gold plated one stainless steel or titanium alloy Which we can insert it manually Or by using low speed Last type hand piece What are the factors which affects the retention of pin in dentine and amalgam So the first one is type of pin The type of pin So in type of pin We have self threading So this is the most retentive one Self threaded is the most retentive one And then we have friction Friction lock So it should be like this Friction lock And the least one is cemented one So this is the order of retention Most retentive is self threaded Then friction locked and cemented pins Second thing is surface characteristics In surface characteristics The number and depth of the elevation on the pin That is the serration or thread It depends on the retention So the self threaded pin has got more threaded surface It is giving greatest retention Then the orientation and number Orientation Orientation and number So if we have a non parallel pins It gives more retention So non parallel pins If the pins are like this It gives more retention And bending of pin is not desirable It should be straight So if bending is there It will interfere with condensation of amalgam And it results in weaker pin And also create fracture in dentine And if we have more number of pins More number of pins It results More retention But problem is more Crazing and fracture chance Decreased amount of dentine available And decreased amalgam strength Next we have the diameter of pin So if we have greater diameter It will increase the retention Diameter Diameter is high Retention also will be high So the danger of perforation On pulp or external tool surface Is there when we increase the diameter And it interferes with condensation Of amalgam and adaptation to pins Then we have extension into dentine And amalgam Extension Into dentine amalgam So we have retention It does not increase when depth of the pin So if it is more than 2 mm in dentine It will fracture the dentine And if it is more than 2 mm in amalgam It will fracture the amalgam So the most ideal one is 2 is to 2 Because both the case If it is going high It is more than 2 mm There is chance of either amalgam or dentine So here we have amalgam So now regarding the pin placement and techniques So the number of pins So several factors must be considered When deciding the number of pins It is such as the amount of Structure amount of dentine available To receive the pin On amount of retention required And size of the pin So the number of pins The rule is one pin For missing axial line angle So this is the rule So one line angle That is axial line angle is missing We can use one pin Similarly more than one So excessive number of pins It will increase the chances of fracture of tooth And weaken the amalgam restoration Now the location of pin So several factors aid in determining The pin hole location So we need to have a very thorough knowledge Of normal pulp anatomy and external tooth contour The current radiograph of the tooth should be taken To understand the proper orientation Of the canal And patient's age also is a factor So occlusion clearance should be sufficient To provide 2 mm of amalgam over the pin And pin hole should be located Halfway between the pulp and DEJ And at least 1 mm of sound dentine Around circumference of the pin hole If this is the pin hole There should be 1 mm dentine That is 1 mm sound dentine should be there Around the pin hole And pin hole should be located Halfway between the pulp and DEJ That is 1 mm inside DEJ Pin hole should be located In areas where greater stress occurs That is the first thing That is regarding the distribution of occlusion force It should be at an area where the greatest stress is happening Then it should be located near the line angle of the tooth Or the marginal ridge or cusp tip That should be parallel to the adjacent external surface But not closer than 1 to 1.5 mm And it should be prepared on a flat surface If 3 or more pin holes are placed It should be located at different vertical levels on the tooth Not on the same plane It should be at different vertical levels One here, one here, one here Not on the same level And interpin distance depends upon the size of the pin And maximum interpin distance results in Lower the level of stress in dentine Now regarding the perforation Which may result from pin hole placement So over the prominent mesial concavity of maxillary first primolar So maxillary first primolar There is always a concavity on the mesial side So there are chances of external perforation And at the mid-lingual and mid-facial bifurcation Of mandibular first and second molar We should also be very cautious And at the mid-facial, mid-mesial and mid-distal Perforation of maxillary first and second molar All these locations we should be extremely cautious Not to perforate the tooth So in pin hole preparation The number 1 by 4 burr should be used to prepare a pilot hole It is to permit more accurate placement of the twist drill Then prevent the drill from crawling Once it has begun to rotate An optimal depth of pin hole into the dentine is 2 mm And this hole should be prepared on a flat surface And the drill perpendicular to it Plays the flat thin-bladed hand instrument into the crevice And against the external surface of tooth Which indicates the proper angulation of the drill So what are the causes of failure of pin-retained restoration? So we can have failures at various levels So if this is our pin-retained amalgam So we have amalgam here So occur at 5 different locations That is a fracture occurred at 5 different locations One is here This is a restoration fracture here That is a pin restoration separation At the interface between the pin and the restorative material So this is the amalgam restorative material This is the pin So between the interface Now we have third fracture here That is the pin fracture That is happening within the pin So the pin will be fractured Now we have the fourth fracture That is pin dentine separation At the interface between the pin and dentine So it will be here This is the pin and this is the dentine So there will be fracture here And finally this is the fifth one That is dentine fracture That is happening within the dentine So these are the 5 locations where the fracture can happen So problems that arise during the pin-retained restoration The first thing is the broken drills and pins That is a twist drill will break If it is stressed laterally And allowed to stop rotating before removing the pin-hole And if you use a dull drill Pin will break during the over-screwed In the hole If you are trying to over-screw the hole The chances of breakage of pin So loose pins Basically due to Loosen while shortening with a bur And pin-hole prepared is too large In these cases the pins might be loosened And next thing is penetration Into the pulpan perforation of external To surface We already discussed that Where we should be very cautious And then there are chances of lateral perforation And also apical to gingival attachment The placement will be apical to gingival attachment So these are the problems associated with pin-retained restoration So we discussed in detail about various types of pins Its placement and the cavity preparation Requirements And the failure details of all these pins And its advantages and disadvantages This is a commonly asked essay question In university paper So I hope you understood this concept Of pin-retained amalgam restoration Where we use pin to provide a better resistance And retention to the amalgam restoration So I'll come up with a new topic in the conservator industry Thank you


If you don't know what this little creature is in the bottom right when when Lincardie graduated we had to Pick a mascot, you know, because they have all those cute little animals for Kubernetes and for go and all that and so we tried to pick we tried to think of like what was the least cute animal that we could pick and lobster was the one that we ended on and It's actually a blue lobster, which is very rare, you know So if you ever see one of those in the wild don't don't eat it And then we had to answer a bunch of questions about like it does a slobster what what gender is a lobster and I did a Lot of research and it gets complicated so I'm gonna leave that for for you all to research at home how to tell, you know The gender of a lobster all right. I changed the subtitle just now those of you who were in the audience Saw me do this live. I promise it being here does not make you a boring person despite It's very boring title and the fact that I am boring. I'm gonna try and make this really exciting This is our Lincardie maintainer kind of project update that we get to do every kube con So I really appreciate you coming out here and listening to me and you know feel free to Raise your hand if you have a question at any point I'd love to make it more interactive and not just me mon logging, but I may get Lost in the in the beauty of what I'm saying. So, you know, we'll see how it goes All right, this was supposed to be delivered by Alex Unfortunately, Alex is filling in for another talk So I'm going to be delivering this in her stead But Alex will be delivering a talk that probably will be much more interesting than this one called five years of cloud native Rust that's today at 230 on level three. I think you can if I did my qr code right You should be able to just scan that otherwise you can just type in one r2 qn One of the things I'm only going to mention very briefly in this talk But Alex is really going to go into is the investment in rust that we've made so, you know It's been as you can see five years And a lot of what makes Lincardie great today comes from this very early decision And you know a lot of kind of the pain and suffering that came along with that to adopt rust and and to adopt This very particular approach where you know every aspect of the of Lincardie's data plane is You know it's kind of informed by not just rust but around the asynchronous network ecosystem That's been built up in rust. So please do attend this talk This me William Morian. Thank you for being here. I used to do this talk a lot and I actually haven't done it for a couple years So, you know, we'll see how it goes. This is a picture of me fixing a toilet in the very early days of Lincardie development This was basically my best contribution to the project Arguably at least that's what some people have told me. All right I'm gonna do a very brief intro into what Lincardie is and you know if you've seen this a thousand times before then You know just bear with me. It's a service mesh. I'll spend one slide describing what that is It's known for being light for being fast for being security first and it's also known for being Simple and that's really the focus for us created by a company called buoyant, which I love And please, you know pay us a lot of money Seven over seven years in production 9,500 slack channel members We're we're close to hitting 10,000 So if you haven't gone to slack.linkardie.io, you don't have to do anything just sign up so I can get this number to 10,000 If I see anyone in here who's you know at the next talk at Kubcon Paris next year and we're not at 10,000 I'm gonna be upset at you for not joining Make sock puppet accounts if you need to everything's fair in the you know in love and cloud native Lots of github stars lots of contributors Weekly Edge releases and so on we were the first service mesh to graduate the CNTF a couple years ago And our job, you know the job of Lincardie is to give every platform engineer in the world the tools that they need to Create secure and reliable and observable cloud native applications. So hopefully that resonates with you If not, then it's may be a very boring talk. All right, it's a link Lincardie is a service mesh I promised I'd spend one slide on this You know so the way I think about this is a service mesh is an infrastructure layer, right? So it's not something that the developers have to interact with directly It's something that should be kind of provided to them as part of the infrastructure It's at the platform layer and you know in a way It's kind of like this modern L7 capable network So if you come from a networking background you're very used to you know what I would call L4 Stuff, which is you got packets and you know you've got IP addresses and you're trying to deliver packets from this IP address to that IP address I know I'm like summarizing a lot of stuff in you know in a really short way And then for but for Lincardie we kind of think we're thinking about things in L7 versus L4 which means we're thinking about rather than IP addresses. We're thinking about workloads, you know Or rather than and workload identities You know rather than TCP connections and TCP packets. We're thinking about HTTP to connections and gRPC messages and things like that and and so it's it's kind of a different level of Networking and you know the goal for us is this should be uniform across your entire application So all these benefits, you know you get kind of regardless of what the application was written in and what team wrote it You shouldn't have to change your application for the most part. That's true There's always one or two little asterisks that we have to navigate through And then our implementation as I mentioned is this idea called a micro proxy So we build it in rust try and make it as small and as lightweight and as single purpose as possible So if you're familiar with Envoy, it's a general purpose proxy. The Lincardie proxy is not general purpose You can't use it in any context other than Lincardie And that is part of what allows us to make it slim and trim And then we've got a control plane off to the side that kind of manages as proxies for you and gives you the Interaction points, you know through CRDs or elsewhere To interact with Lincardie as a whole this makes sense so far to everyone Okay, I see a lot of nodding heads. Thank you. Come on in. You're not too late. I'm just going through the intro stuff All right, what makes Lincardie so darn good So for us, we got a couple kind of design goals One is we want to make it just work so we want to make it so if you have a functioning Kubernetes application Runs today and you add Lincardie the application continues to function and you know 99% of the time we can do that Of course, there's always one or two asterisks And it's also a very good way of finding out whether your developers have obeyed The standards when it comes to things like HTTP calls have they made Assumptions about header ordering or about header casing and things like that, you know, that's that'll be a fun Fun discovery for you as you add Lincardie Because we do require those things we do require the applications to conform to those standards Ultralight, of course, I've talked about simple to operate You know, that's kind of our promise to you is you are the poor souls who are going to be on the hook For waking up at three in the morning if this thing goes down, you know We want to minimize that as much as possible and we want to give you the ability to just have in your head Like is there a model of how this thing works and when things are behaving, you know Contrary to that model you can ask a really informed question rather than just believing it's this black box of magic You know complicated stuff And then of course we want to make it secure You know and and treat that as kind of like the default behavior Not as something that you have to enable or configure to the extent that's possible Okay control plane data plane, etc These slides are basically Online so you know if anything I'm saying goes by too fast you'll you'll be able to to find them All right the data plane that I mentioned rust microproxies not using envoy Okay, this gives us a whole bunch of interesting kind of characteristics You know part of this is it's part of our security first approach So rust allows us if you're not familiar with rust really interesting language You know Alex's talk later today will be we'll have a lot more examples Actually, I think she's got examples of what things you can do in C++ that are terrible that the rust Compiler will not let you do so there's some fun the kind of code side-by-side stuff there But it allows us to avoid an entire class of memory vulnerabilities that are basically endemic to you know C and C++ code turns out no human being in the world can actually write safe C++ code Beyond hello world maybe ultra light ultra fast, you know, so we compile a native code State of the art networking stack all sorts of fun stuff in here You know and really we want to we want to make this thing an implementation detail Right, so if you are a service mesh operator, you should not and you become an expert in linker D You should not have to become also an expert in the linker D proxy All right now let's get into the controversial stuff. This is my opinion. Well, okay. Yeah, that's my opinion So there's kind of three, you know, if you're very familiar with the service mesh landscape There's kind of three approaches people have taken there's node proxies Which actually came first because of the very first version of linker D was node proxies There's sidecars, which is what we are today and then there's this newer idea of ambient Ebf ebpf comes up a lot in some of these conversations It's basically a red herring because ebpf is great for l4 features Right, we talked about the network and packets and things like that. It's great It's amazing for that, but it can't really handle l7 features Not the way that we that that the service mesh needs it to handle Because the way that the thing works is it is limited by design because you have to run these bytecodes in the kernel Right and so you have to be very very strict on what you're allowing to run in the kernel. So that's fine, right? It's not a knock on ebpf. It's good for some things not good for other things But what happens is when you make a sidecar free ebpf service mesh You end up using node proxies and that actually is bad, right? Because node proxies mean that you share all the TLS information It means you share all of the requests from very disparate workloads all going through that single proxy We saw this live with linker D in firsthand with linker D one dot X which was node proxies and You know a lot of the initial adopters from of linker D one dot o Told us how painful this was so that was part of the kind of reinvention of of linker D You know circa 2018 to move into the sidecar world Ambien is better. I'm not going to talk too much about that. It is very complicated But at least has better security properties We did do a long exploration of ebpf. I think the TLDR and if you read this Blog post that I wrote about it. I think it's likely will add ebpf at some point to linker D But I don't think it really is going to change a lot for it Sidecars and micro proxies are the the best solution after doing a thorough analysis They continue to be the best solution For for serious users. They have a really clear operational and security boundary, right?  Those are slowly being Fixed at the kubernetes level. So there's some really cool stuff happening with the sidecar Sidecar containers and stuff like that. I wrote a little blog post about this 1.28 was when they when those first came into alpha and 1.29 and they're gonna I don't know They're getting better refined in some way. So that's all to say at the end of all that You know ebpf probably is on the roadmap for linkerty, but I don't think it's gonna change a whole lot It's gonna have a pretty minor effect. Okay I'm gonna jump with that. Let's see. Oh, we're doing okay for time But I'll jump into Kind of a little history of some of the recent releases and then I'm gonna end with kind of what we're building in the in the next release So 2.12, which is gosh, I don't even remember when this was a couple couple releases ago Introduced security policies that were per Route so the the security model for linkerty is that we can enforce remember them because we have the sidecar And we're kind of in you know at the at the pod boundary Right and all traffic before it can touch the application on that pod has to go through the proxy The security model is at that point we can actually enforce You know what kinds of requests are allowed to talk to the application and you can describe those requests You can describe them in any way that you want You know you can describe them based on IP addresses But you know we're trying to move to the security model of future where we're talking about workload identities and things like that So you can describe them in terms of workload identities and you can describe them in terms of routes So you can say I am service B your service a and in order for a to talk to be You know it is allowed to talk to be you know on the slash foo endpoint But not on the slash bar endpoint things like that Right, so this is what we're talking about workload identity and kind of per route or per g rpc method granularity The way that we implemented this is using this thing called the gateway API and I'm gonna talk a little bit about the gateway API because it's kind of a Recurring theme for linkerty and it's kind of this future direction we're headed So this is an example of an HP route that permits certain requests to a server Which is a you know another type of object called the author's server And so you know the goal here is we want to give you kind of this really granular level of control But we also want to do it in as standard a way as possible So rather than implementing, you know linkerty specific CRDs We try and do it with the gateway API again. There's one or two asterisks to that statement But by and large that's that's a goal right and then 2.13 Okay after that so that 2 to 12 is very security focused right giving you those policies 2.13 now We're getting into Kind of back to the world of routing away from security back to the world of routing and giving you a similar capability with request routing So giving you the ability to say I want to route traffic, you know Not just based on the kind of the DNS Name but based on headers based on verbs. We don't look at the body for a variety of reasons But this is a very fine grained way of routing requests kind of dynamically based on these routes Again configured with the gateway API Not with SMI components if you've been a linkerty user for a while You're probably familiar with traffic splits and things like that. Those were based on this SMI API in the modern world. We're trying to move off of SMI on to HTTP route And so we use that same object that was introduced in the previous release Great So now we've you know now we're starting to have like a really uniform Configuration space and there's all sorts of interesting examples of how you can build upon this to do things like You know per user canaries and stuff like that The other thing we introduced here was circuit breaking So this is something you know I think came a little late to to the linkerty probably should have done earlier And the idea here is like if an endpoint is failing, right? We should just stop delivering traffic to it because we know it's failing and because Reducing traffic to it might allow it to recover right it might be dying because there's too much traffic So if you've got too many consecutive failures if the success rate is too low Then we're going to turn traffic off and then as it recovers So we're going to ping it every once in a while when it recovers. We'll start sending traffic back to it So that was 213 and then finally 214 is the most recent release So this is Flat network that's where we introduced flat network multicluster so in 2.13 and earlier so linkerty has had multicluster Capabilities for a long time and by what multicluster means in linkerty's cases the ability to send traffic from one cluster To another kubernetes cluster in a way that's transparent To the application so the application, you know Again, I'm service a and I'm talking to service B All I have to do is connect to be like the normal way that I do and I don't have to know whether B is on the same cluster It's on a different cluster whether it's like halfway in between these Clusters because I'm splitting traffic across them whether I'm the middle of some kind of failover operation. That's all independent you know from From from the application's point of view right you just talk to the service and so that gives you a lot of flexibility You know under the hood the way we implemented this was with a with a gateway. I'm sorry. Is there supposed to be a gateway? Picture here. Okay. There we go. This makes a lot more sense, right? Yes under the hood we have a gateway on the destination side, right? So if you're workload one and you're talking to workload to it goes through this gateway object, right? And you don't get application doesn't know about that That's kind of happening under the hood the reason we did that is because the primary use cases that we saw for multi-cluster and Kind of the early days of linker D We're kind of these ad hoc use cases where I have a cluster over here and now you know separately We add this other cluster over there and it might be on a different cloud or it's in a different zone Or it's like, you know owned by a different team And so this gateway based approach was really nice because all you had to do the only l4 requirement that you had here was You need to be able to establish a TCP connection from the cluster on the left to that gateway But that was it right we didn't make any other assumptions about the underlying networking now what we've seen you know more recently is If you underline network allows pods right? Yeah, great So right so if you actually do your network setup, you know in in kind of a more forward-thinking way And you can actually route the pods, you know pods can route traffic to each other Well, then we can get rid of the gateway right and then you end up with a very Very boring diagram that looks like this, you know again workload one doesn't know where workload two is So linker D is kind of taking care of that under the hood for you But then you can you know, you can get rid of that gateway component This has a couple other nice benefits. Of course, you're not going through a gateway. So that's one fewer hop and You know, you also preserve the identity on the from the left-hand side. So that's kind of nice Yeah, sure Yeah, so the question was what do you mean by an underlying network that allows you to do this So yeah, this is basically a shared flat network So you have all the pods and my network, you know engineering knowledge is about one level deep So I'll describe this as best I can but it means that all the pods are can route traffic to each other So they're on the same shared flat network. They have IP addresses that are unique across all Clusters not just unique within the Yeah, that's right Yeah, that's right. That's right. And if anyone wants to correct me on what that means Raise your hand Don't nap between the pods go straight from pod sider to pod sider Okay Thank you. Yeah So, you know, it's an alternative mode. We didn't throw away the first mode This is just if you're in this situation. Hey great, you know, we can save you a component And you know all sorts of interesting engineering challenges that I was kind of you know Half exposed to here around services covering and things like that But the details are all in the you know the docs and blog posts and stuff around that The other thing we did in 2.14 is we officially became conformant with the Gateway API, which is you know Again, I keep using those words. Basically the Gateway API was or is a Set of API is that was originally designed to replace or to You know provide a successor to the ingress resource so the ingress resource which we all know and love You know was something that we often had to work around because it was so limited the Gateway API was designed originally To have this really expressive set of CRD is that you could use you know to describe the full set of you know behavior you want on on ingress and they did a really good job in designing this API they did such a you know So good of a job that actually a lot of it applies to the service mesh. So at some point You know that that the Gateway API team said well, gosh Let's actually make this you know work for service meshes as well as for ingress And so they added this idea of different profiles and there's a mesh profile Linkerd was a very first service mesh to be fully conformant with the Gateway API mesh profile It's really exciting if you're like a deep Kubernetes nerd if you're a user I don't know that it really is that interesting except to say that It is a step towards a goal that I'm kind of excited about which is we have a fully uniform set of configuration for linkerd and for ingress with the same set of API's same set of you know CRDs and types and things like that and I think that will be a big benefit because then You know a you have some you know You have some flexibility in terms of like you know Here's the API for controlling my service mesh and maybe I swap out the implementation Underneath without having to change any of that and be you have one set of things that you're thinking about when you're configuring ingress And for measure one set of tools that you're working with I guess when you're configuring those two things and to me That kind of makes sense because a lot of the constraints, you know and and goals are the same There was you know things got a little the this standard is still evolving So there are one or two warts where when you're actually trying to do this But so this is a kind of I would say this is a stepping stone But maybe not the you know, we're not at the final end state yet All right, so 214 was our most recent release now finally we're going to get to 215 So this is an exciting kind of announcement time So the goal for the next release is to add mesh expansion just the ability to add Off cluster non-cubanet ease things into the mesh so that means we can run the data plane outside of Kubernetes so on the one hand that's really really easy because you know these rust Microproxies will run anywhere like we can compile them for any architecture and they run You know, it's just a binary. They're actually you know We did one clever thing early on which is we did not make those proxies Kubernetes specific at all They're linkardy specific so I need to talk to the linkardy API But they don't know anything about Kubernetes They don't have any assumptions in there that they're running on a Kubernetes cluster or even in a in a container, right? They're just regular old-fashioned binaries But you know, that's the one simple aspect every other aspect of this is really really hard There's a whole set of challenges around well. How do we do service discovery? How do we do you know network connectivity when we're running within Kubernetes? You know, we have all these assumptions we can make Kubernetes gives us all these primitives that we can build upon we can You know, oh, you need to get the you know the sidecar You know into every pod. Well sure you just use a mutating admission web book controller and you know there you go When you're out in the world the VMs well, you don't have any of those primitives So you have to decide okay, which of these you know, are we gonna actually rebuild and which of these are we gonna leave as a burden for you? right the user one that I want to talk about briefly here because You know this one became really interesting with this idea of workload identity So all the policies that I talked about earlier and in linkardy 2.12, right? All of our kind of like authorization, you know framework is based on this concept of workload identity We don't want to use the IP address. We don't want to trust the network, right? We want to trust cryptographic proof of you know of strongly attested workload identity in Kubernetes land we can use your service account as a workload identity because that you know for purposes security is basically Tantamount your identity once you're outside the cluster. Well, we don't have that anymore, right? So now we have to come up with a way of Providing identity for like an arbitrary application on an arbitrary VM turns out there actually is a project That's basically solved this so that's great for us. We don't have to reinvent the wheel. It's called spiffy inspire Does anyone here used spiffy or is using it today raise your hand don't be shy I see one half-hearted hand on the far right Anybody else That's it. It's a graduated project Is anybody too embarrassed to admit that they use it raise your hand. Oh, there we go. Okay two hands. Yeah All right. Well, I don't know what them. I mean gosh, okay Maybe this was a bad idea Well, mostly I just don't want to have to rebuild all this stuff. So, you know Right. So, you know and kind of the division here Is that spiffy is a standard, you know and inspire is effectively a reference implementation And all that spiffy does is it says hey if you take a you know It's called an x509 certificate and you format, you know these fields in this way Then you now have a spiffy ID and you know, there's more complicated in that There's like a jot version a JWT version and things like that But it turns out those those, you know those x509 certificates are exactly what you use for TLS and including for linker D's mutual TLS so that integration is very very natural now the question is okay if I have a standard for you know Presenting identity that's kind of already implemented in in in linker D Well, how do I actually get the identity for an arbitrary machine and that's where spire comes in so you run spire spire gives you a spiffy certificate for you know a workload or you know, or whatever you're trying to attest So we're basically a late prototyping stage with this it's going along really really well I expect to have a stable release. I should never do this I should never put a date on a slide in a recorded fashion So editors just beep out the next section, please but early next year. It's looking really good And I just wrote a little blog post about this a couple days ago if you want if you want to learn more Yes, sir Yeah Great question. So question was does spiffy inspire for anyone who's using it out there Does that interact with certain manager? You know, does certain manager do anything with spiffy inspire? What about the one half hearted hand over there? You want to you want to tackle that? Okay, so he believes spire would be doing the rotation and management anybody have a different opinion. Yes over there Sir manager does interact with spiffy inspire. Okay, great Okay, there's a combination you can use Yeah, okay, great great. Yeah, great great question though Any other questions on this yes, sir? Yes, that's right. So you would run the product question was do you run the proxy on the VM? Yes, yeah, you run the proxy on the VM What you know, how much help we can give you in Delivering that proxy to the VM and getting everything set up and all that is it's kind of what we're exploring now But ultimately yes that proxy sits there it gets an identity not from Linkardy CA sitting on the cluster but from from spire and then it establishes a connection to the control plane Any other questions on this? I'm really excited about this because you know finally gets back to the In linkardy 1.x for the elderly amongst us here remember that we actually were able to run on VMs and you know on Mesos and on nomad and like it you know is totally orchestrated Independent and I'm excited to be able to at least get partially back that way control plane still has to run on Kubernetes So we're really talking about the data plane that gets to expand And this is also a good lesson why you should never raise your hand when someone asks a question because then you'll be called on to you know Answer a follow-up questions Okay, and that's really it we've got six and a half minutes left So we can do a little more questions than answering if you want to get involved of course you can talk to you know You can talk to me all the development is happening on github. We have slack linkardy.io, which please everyone joins we can get to 10,000 people there We've got mailing lists if you want the formal announcements. We do the CNCF funds formal third-party Security audits. I think we have a pretty friendly and welcoming Community I do have two quick ads and then we'll jump into questions Boyant itself runs these free engineer focused training things called service mesh Academy So if you are interested in learning more about linkardy Myself and a couple other of the linkardy folks do deliver this educational content I think it's pretty good. We get pretty good reviews. It's all free. So you don't have to do it We also have an enterprise distribution if you're running multi az clusters, especially and spending lots of money Please come talk to me afterwards And that's really it so five and a half minutes exactly remaining any questions Let me I'm gonna come to you in a second Amir. Let me start over here. Yes, sir Yeah, great question. So the question was you know linkardy the data plane leases written in rust What has the experience been like? You know, what kind of advantages what's been bad? The the right place to learn more about that is at Alex's talk at 2 30 Because she's gonna dive into all of that stuff. I'd say for my perspective It was a real gamble early on because Rusty in 2018 was like You know the language was there, but the ecosystem was like barely there It's really paid off though like almost everything that I think is really powerful and unique and and and amazing about linkardy is Because of that choice Yeah, great question, but do do go to that talk All right, Amir I do have some updates about point cloud But I don't want to talk about them here because I want to keep it as open source as possible But thank you. I appreciate that question. All right. Yes, sir networking expert in the middle So the question was when you're doing mesh expansion, there's configuration Does that configuration happen on the VMs or does it happen on the cluster? I actually don't know the answer to that question I would my my guess and you know Flynn back there, please correct me if I'm wrong My guess would be there's gonna be an amount of configuration that has to happen on the VM because you have to tell if nothing else You have to tell the VM Where you know where linkardy is? All right. Yeah, come come find Flynn or find myself Afterwards and we'll figure out the right answer. But yeah, great great question. All right Anyone else another question? We're gonna sit in silence lock the doors. Yes, Joe, please Okay, so the question was Joe here is a cheapskate and has GPUs And you want to know can you can use mesh expansion to bridge the GPU and your and your local Kubernetes cluster? Yeah, my understanding is yes as long as those GPUs can run like, you know, a Binary Linux, but you know I have enough Linux primitives that we can do like the networking stuff that we need to do and can run a binary Then yeah, that should be just fine Yes, sir Yeah, great question. So the question was multi cluster. Is that primarily targeted having money many clusters in the same region or? Could that be used for you know clusters in different regions or different clouds the gateway approach kind of the original approach Doesn't care. So yes, you can use that in multiple clouds We have adopters today who you know are doing a multi cloud approach and tie these things across You know from one cloud to the next the that gateway connection is MTLS, you know So it's secure you can put it over the open internet and you can feel confident in that the flat network approach Doesn't work across regions. You need to have like the the L4 L3 L4 capabilities, you know sort it out there. I Believe please green hat correct me if I'm wrong All right, we got time for one last question Yes Yeah, yeah, okay. So the question was we've talked a lot about the linker deep proxy But linker D also has an init container. It has an optional CNI like plug-in thing. How does eBPF play with all of that? I so the way that I see eBPF working with linker D and Probably I'm gonna be corrected on this But my guess is the thing that we can do there That would be most useful is if you're doing a pure TCP proxing through linker D and you're asking us not to do any L7 metrics at all because this is an application initiated TLS connection For example where we don't want to man in the middle it or it's you know some TCP Stream where you're just like I don't care just get it to the other side We could use eBPF to bypass the proxy and just like wire those two things together Would that be done at you know through the init container through the CNI level? I don't I don't know I'm not sure but that's that's the intersection of the all of those words that you said That I'm aware of all right. Thank you folks really appreciate your time here today I'll be here so come up and ask questions and use linker D


What's up y'all? It's your girl Kenzie here from Layton Sports Cards and I'm ripping some personals here for Eric R. We've got two 2022 tops five star baseball hobbies, a 2023 boom baseball jumbo, and a two 2022 tops triple threads. All right, good luck Eric. We're going to start with the five stars. Good luck. First, we have purple six out of 50 Jackson Reets, Brewer's rookie auto. And the second hit, nice one here. I'm going to CJ Abrams rookie base auto. Nice Abrams. Quadres. Two rookies coming out of that first box there for you. We have two 75 Patrick Mazzica on the green rookie. Metz. And nice one here, Eric to end your five star about rookie auto Bobby with junior. Congrats on that one on the base auto. Wow, all four cards being rookies. Grats on that Eric. We'll get that one in the bag for you. Do the triple threads next. Two 2022 triple threads. I don't have my nails done because that would have broke my nails. Frank Thomas Clemente to 299, Mel on. And two 150, George Brett. We have 21 out of 27 Brace Harper on the power source. Game used memorabilia there. And triple thread autograph single jumbo relic of Dan's Be Sponsored with the Braves. Perez, Wander, Franco, rookie base, Buster Posey, Juan Soto to 125 and 2199, Alex Bregman. 24 of 27 among the greats of Ivan Rodriguez. Cool on there. Among the greats. And jumbo bat relic is going to be one of 48 Chris Bryant. Right. These are personals now. Triple threads number two. Yeah, we are on two personals. Another redemption here. Trevor Story, Randy Johnson, Shriver Jones, we have 250 Robin Yell and many Machado to 259. Redemption is going to be Future Phenom's autographed relic card gold parallel of Alex Kearlaw for the twins. Nice Kearlaw. And jumbo patch here, 16 to 27, Alex Bregman for the Astros. Alex Bregman. Jared Kellnick, Carlos Correa, Tony Gwynne, got to 199, rookie Bobby Wood Jr. and green to 259, Shriver Jones. Got the pizza man, the legend, 13 of 36, Mike Piazza. Some jerseys and bat relic there. And to 75, rookie auto pirates of Rodolfo Castro. Right. Now we've got your Bowman jumbo here for you, Eric. 2023 Bowman baseball jumbo. Just a reminder, no paper based ships out of this. Spotlight, Jackson Holiday, Marcella Meyer, got Lunar Glow, Perosa, Brooks Lee. First auto up, it's going to be Red Sox, purple to 250, Luis Revello. Revello there, Red Sox, Josh Young, Oswald, Perosa, Hopay to Mark Johnston, Rito Clifford, Carl Armstrong. Next auto up, we have a Stompe, Tommy Speck, 51 of 100. Nice one there on the Atomic. Love Atomic cards. Got a blue Shriver coming up here, Cruz Amaro, and it's going to be a Jackson Churrio, 18 of 150. Elijah Green, Paper Adley, Comanera's Prospects, Lugo, Guilarde, Jordan Walker. Walker, Solas de los Santos, Gomez, Mervis, Andrew Romo. Got Invicta of Danny Dandrade. Mitchell, Churrio, Barry Chrome. We have Aqua Creator to 125, Marcos Cabrera, Yankees, Wells. No, we might be out of those. We might be out. And we've got Base First Auto of Jefferson Rojas. Painter. Didn't get a crazy amount of that in. Crawford, Artega, Max Muncie. We have Rookie Francisco Alvarez on the Spotlight. The Los Santos Prospects. And some Mercedes-Lee and Mazzardo. Casas. Got Blue Paper First of Kenny Gomez, 13 of 150. Garcia, Junior Camarino, Wagner, and Pedro Leo. Alrighty, Eric, that will do it for your boxes. Thanks as always for hopping in and for all your support. And we will get these cards sent right out to you.