Mark. Mark, are you there? Yes, I'm here. Just had a hard time finding the mute button. Sorry. I just want to make sure that you can actually hear me. Yep. Sounds good. Oh, the other mark. Hey, Mark. I think Sarah made a mention that she can't make it. So hopefully at least Clemens can make it since it's really his PRs that we're kind of talking about. So let's give him a few minutes. Hey, Stanley. Morning. Afternoon. Thank you. Good evening for all our, for everyone else. Yeah. I wonder if somebody does that on a call. The first thing that went through my mind is just say hello. I'll cover it. I really like pink Clemens. See who's going to make it because I think he said he was going to make it. So we'll say, let me share my screen. So I had to leave early yesterday.  Yeah, I'm, I know I was there and I think Mark peak was there as well. Do you want to summarize what happened at the end? I know, I think what I heard you guys did make it through the other two points in PR 117. I guess talking about middleware and framework. What happened after you left that PR? What were the topics that were discussed? I'd be curious to hear kind of like Kathy and, and or Clemens and or Sarah's take on what was discussed, but it, it kind of felt like we devolved again, like things went off the rails a little bit. What was the, well, what was the supposed subject? Request and Mark, do you have anything comparable to So I was, I wasn't on the call yesterday morning. Oh, you weren't. Sorry. I popped on to the one on Monday, but not yesterday. Well, Stanley for 117, do you think there was general agreement on that call yesterday about its direction. And it was things only derailed once you left 117 or was it within 117 that things kind of weird. So we were talking about, sorry, I'm trying to dig down to where the points actually wound up. So you, you were there for points. One and two, you said, right, and then for three and four, we were going to continue on. Yeah, because I, yeah, well one and two were mainly the first day, which I guess is Monday, then yesterday I left, I think halfway through number three or something like that, if I remember correctly. No, I think we actually we did make some progress in the The assumption was we were going to so Clemens and or anyone else interested was going to write a separate action related to a right a separate issue related to clarifying middleware. That was really kind of where the things started to fall apart was middleware can be, you know, message brokers, it can be, you know, API gateways, it can be any number of things and part of the problem were you here for this by the way Doug, or had you left by that point when we started this discussion. Yeah. So I think I left when I remember it with one but either way like my in in kind of sitting through the discussion it felt like we were kind of mixing and matching use cases. And it's, it drives some of the confusion when we say middleware, I think, um, that there are so many things we're trying to consolidate until like this one statement. So there was a probably like there will likely be a separate issue filed to kind of clarify the different, you know, use cases and different potential implementations of what middleware will actually look like in the world, because it was driving you know, from an IOT perspective right like versus using message pack versus like a Kafka perspective using just, you know, schema, like obviously like validated, you know, messages say like the Avro or whatever it is. Right. Um, the idea just generally was that and then let me see. So, Clemens joined the call now so hey Clemens. I was just asking for status on where we left off yesterday since I had to drop early. Hi, dog. This is Kathy. Hey Kathy. Yeah. So I think you know we, we were in number kind of number three. You know, the could just screw up on we talk about the yeah I think I just follow up on the on the on the middle where I think we would always said we agree we will add some example there, like because you know, I don't know who was speaking before. Is it come to stand. Okay, so I think we were saying, you know, yeah, this middle where it's a very generic terminology would like more clarification that it could be some this definition of the middle where it looks like it could be, you know, a service platform, it could be a router and it could be many other things. So we're like, at least give some example. Okay, but it sounds like, but it sounds like from what Stanley was saying that that may be something that we can do in a follow on poor request, right? In the following, you mean in a separate document. No, no, in a in a in another poor request after this one. Oh, okay. Okay. Oh, another poor request. Okay. Yeah, just just so we can make some forward progress. Okay. But it's so hey Clemens. You there. Clemens, I think you're on mute if you're talking. Oh yes, I am. There we go. Hi, sorry, I was held up by technology. Not a problem. So we're just trying to figure out where you guys left off yesterday and what the next steps are based upon where you guys left things. So my understanding is we were through. There were also comments that were filed on this stock on this part of the document. We left and then I addressed them all. So I think we're my understanding is we're done with this. And then we have, we veered into a discussion of one of the items because someone asked like what the namespace stories about. So we talked about that a little bit. But what that might mean, we don't have a, we might do a clarification. I think what that ends is that we're going to do a clarification of the of the meaning of the field or probably have a discussion about that separately. And then I think that's where we were. Okay. So it sounds like 117 is kind of behind us and that we're moving on to a particular attribute whether it's namespace or one of the other ones right. Yeah, so I think I think the namespace is one where it's for me, it's it's a nice to have it's not so central. Okay. So would it be then wiser to talk about a different attributes that we can get hopefully quicker agreement on. Yeah, so I would like to talk about plus 95. Okay, what other people think about number 95 but I believe because that talks about that talks about specifically about changes to the properties source source ID source type and renames them. Right. And this is topic and subject. Right. Yes. Yesterday we were, you know, discussing what's a relation between the namespace, the classification and the subject right in the. Yeah. And the namespace, the namespace, I want to keep that out because the namespace is basically just giving out or framing to all those concepts. But I don't think you can really talk, argue about namespace unless the inside of it is clear. So which means the topic of the subject is cool. I would like to table the namespace discussion and talk about topic and subject first and then we can go and decide whether we actually need the namespace. Right. Okay, so what do people think? Is it okay? Or do people agree with the next step being to look at this PR and talk about topic and subject? Is that sound okay to people? Or is there some other attribute that seems like it should be of a higher priority? I think it's fine with me. But at a high level I would like to understand, you know, what's the relation between, you know, what we discussed the other PR, which, you know, mentions classification and subject. So that's what we're, that's exactly what we're here for. This one does that. Okay. Okay, so I heard Kathy speaking. Is there anybody else on the call who thinks there's something that's a higher priority? Otherwise we're going to keep hitting on this path. Okay. Not hearing anything. Go ahead and let me know where you want me to scroll to, Clemens. I assume. This is fine. Okay. Can we get a raw view of this? What do you mean? The complete view of it without the changes. The new one? Clemens, can I make a suggestion?  I don't know. Just give us an idea of what you have in mind. I know that we can dive into detail of each field. Yeah, so that's why I actually pointed yesterday at the end of the call to issue 117, I think, or 112, which is a five pager that discusses all this. So I'm going to give you the short version of it. Okay, that's good. So there's a ration. So the rationale for introducing topic and subject is really anchored in the reality of the middleware landscape as it exists. More than my own creativity. So I'm just standing on the shoulder of a whole group of giants here who have been figuring this out for a long time ago. So I'm basically just introducing and reintroducing that concept into our space here that where that is also already been heavily used for event distribution. So topic. So it's a two stage. It's a two stage model. And that is very common. As I explain in that issue. There is ample precedent in existing infrastructures for having both variations of both of those fields that are always called that. But there's typically this two stage classification. So from a higher level perspective. The topic is a convention depth that ultimately from if you look at it from really high up. It's a convention that's the producer and the consumer arrive at for classifying events or classifying messages. So that the consumer has a reasonable way to go and select those messages. So I have a few examples here that are shown in the topic section. So let's go and pick. So the US city example actually pick right out of the IBM MQ specification where the and or actually IBM MQ documentation for the for topics and topic trees. Where you have it and you can go and read this and I can probably go and also get food notes if anybody's interested. But that kind of gives a topology classification of events based on US cities and they're grouped by country, state and city. And then you have a sheet component above that. That's something that you would find not necessarily in this nice format. It's a little bit more convoluted in OPC way, which is an automation standard where you have a robot. The robot has a number of drives, the third drive of the third drive. You want to know the temperature. So you have a logical path into that robot towards that drive. Then you might have a resource path and it's just just very generic. That's what most of the services that we run and most other people have. There's a graph of resources that exists and you drive you have a path through that resource graph. That's the top, the top example. That you're mapping and you are expressing as a consumer expressing interest as for events or messages related to that particular resource path. And then we can go through and, you know, for all of these examples, the theme is the same. There's some kind of a resource graph. Sometimes it's a tree. Sometimes it's a little more, sometimes it's more complicated. But you're typically cutting a path through this and this is how you are finding your resources or subjects. And you are registering interest in stuff that comes out of those contexts. Sometimes that context is a little bit larger. So I'm interested in, for instance, everything that that robot gives me. And sometimes that is a little bit narrower. Like I want to have everything that drive three emits from that robot example. And sometimes it's even more narrow. And I want to have a particular, the particular temperature reading only from that robot. So the topic, the topic is in the first place a convention that is being agreed upon, if you will, by producers, but producer crop population and a consumer population. It sometimes will precisely define the originator. But in more cases, it will define a more abstract concept like a, like a categorization. And even in the case of what I just showed you at the robot. The drive you're interested in in the temperature interest in of that drive, you don't actually mean the drive per se, like you don't care about that thing with a serial number. But if a technician goes goes there and exchanges the drive, which means the physical parts and puts another physical part in there, you will now still care about the drive as an abstract thing that you're watching, rather than, you know, the thing with the serial number. So it's a bit, it's a higher level abstraction model typically than, than having a concrete center that you care about. The reason why this topic concept is so successful everywhere is that it provides that level of abstraction that everybody can go and map their, their various contexts to. So you send, you send messages that are belonging to a topic into an infrastructure, and that infrastructure will allow then others subscribers to go and pick messages for that topic. Now, topic is still a fairly coarse, coarse grained grouping. So if you want to then further distinguish messages and more events that are coming out of that topic, which means let's say you want to have all the events that are occurring in the lighting system and the streetlight system of Juno in Alaska, then you will probably want to be a little bit more informed and filter a little bit more. What sort of what kind of event you're looking at. And that's what the subject is for the subject. The topic is the thing you can go and subscribe on to say, I'm interested in events from this topic.  So the topic is the course, the course grain thing that you subscribe for and then the subject tells you what this particular event event is about. That's what these two fields are. And they completely replace the prior notion. So topic is effectively a broader definition of what we previously had a source and then subject kind of collapses onto each other notion of subject type insert the subject ID, whereby I have still not understood what the subject ID stood for. Any questions. Yeah, if I'm understanding properly the Rob the robot drive case, you're suggesting that the temperature and depending on how the user wants to model this the topic could actually end with drives three and then the temperature could actually be the subject. Absolutely. Is there any guideline to how to make that distinction or based on usage.  So the typical way how you would do this in an OPC away for instance, which has a pops up infrastructure that we just added, which is where I can kind of give you the exact exact model. OPC way creates a graph over a composite machine. So it would actually look like this where you have a robot but the robot then has an ID, etc. And that may have a collection of drives on the collection of drive the collection is then the collection of drives is obviously a little bit more, you know, specific than what I have here. It has an identifier that's logical for effective the slot where that sits, and you would put a an observer onto that drive, and then the observer will go and collect the information items you're interested in from that drive. You would compose a message, and that message would then contain all the items that you have so your topic would be the drive in that case because you're particularly interested in stuff that comes out of that drive. And then you would have a message that comes out of that that then carries, you know, temperature and vibration and all those things so the temperature might actually just be in the payload. It seems like this gets into middleware specific issues as well though for cases where you can actually subscribe with wildcards on a hierarchical topic. Yeah, and I think that Matt that actually that fits the case. So, but let's see the topic concept exists in Kafka, it exists in Azure event hubs exists in an event grid exists in Apache ActiveMQ exists in RabbitMQ exists in IBM MQ exists in Mosquito it exists in IBM Q it exists. I like, basically you can go through every pops up broker, whether they're event oriented or whether they're message oriented, where I count versus the MQTT brokers as event oriented. And every single one of them has at least the topic concept. Then there's this the second, the second question is how common is the subject concept. The subject concept is also and I have that in the, in that, in the issue that I filed. I have a bit of a survey, we can, can you pull that up. Pull what up. I have an issue I'm issued that's called goals and etc. and kind of very to the bottom of that I have a list. Okay, I have a question on this topic. I think in the messaging event source. It's, can you hear me. Yeah, I can. Sorry. Okay. Yeah, it's, yeah it's there but how about like for some other type of event source like for example storage. Hang on. Let's, let's, let's get to that to go to the very bottom. It's a doozy. Yes, there we go. So, so here's I actually went and so this entire write up is about almost nothing but topic and subject. And that's why I wrote it to declare to clarify what I mean. And also, but I, I felt it wasn't a long to put in along with that pull request it also predates the pull request. So, SMS as a subject. GCM has a title FCM has a title but they're effectively the same thing. Functionally, Kafka doesn't have a subject as a second level a second order field because it after is gives you effectively your indication about the messages outside of the partition ID and that's a design choice that they made. And GMS has custom properties in instead of a standard as subject fields IDMM queue has also custom properties instead of a standard subject field. And the IDMM queue a MQP binding obviously supports a MQP, the MQP subject field. And MQT also has no subject field per se but also they add custom properties in MQT D five so whether there's a subject field or not is kind of the the the messaging community is split on that but they're not split on with MQT being effectively the last straggler is having a custom property set that you can dispatch on the only outlier and that is Kafka. Would it be horrible if we went with just topic for now and then save the discussion of subject later. Yeah. I still feel where I mean this topic and this terminology is very is very geared towards a messaging event source eventing event event messaging what what is messaging what is eventing if it's not messaging. Like for example if like you know for like give example of S3 like AWS S3 or Huawei's OBS right it's a storage. That's your they have it doesn't have call doesn't have you know topic it has column which column you know it shows which column you know file is saved or is. So it's like a bucket. The way the way how you get how the way how you get at storage events in AWS is you either get the press through SNS or you get them through the what's it called clouds trace not cloud trace watch. Yeah cloud watch I always forget the names. Their stuff is their stuff is always names of complicated and I can never never remember the container stuff. So, so you always get at those events through messaging system. No necessary actually you know, because sometimes you know the event consumer get that event directly from the storage. It doesn't message in system. It just how do you get that. So how do you get an event like this from from storage.    So thankfully, so thankfully, I actually went and did that exact case so go back to that to the to the issue. Who upstairs. Because. Yeah, no. Marks like to sharing his screen. I actually have to drop in a sec so Mark's going to continue sharing and sort of moderating the meeting. If possible, when the meeting's over, can someone write into the agenda doc. The minutes from today and where you guys left off so people can understand what was discussed. Okay, thank you guys very much. I'll see you guys tomorrow, but I need to drop right now. Okay, bye. My concern is I'm not sure whether you know we use topic and subject on. Let me explain that to you. Example, example, go go go up a little bit in that document. Further up further up. Okay, so this is an event as we have it in our is an alert. Okay, so this is an application insights app application inserts operational alert this has nothing to do with the messaging system. Right. It's, it's giving you an alarm, because the disc read was less than. So it's a slow disk. So what I'm doing in this example, I mean the fact that you're evolving this into a compliant cloud events event. So if you just scroll scroll down, I do the step wise so I can go in and tell you all the steps. The first, I'm taking that that event and I'm sticking that into a, I'm sticking it into a container if you can make this a little bit bigger. Okay, so now I'm effectively taking the event that I got and put that into the data field of that event that's the first step that I do. The first step is I'm now saying what that event that I just put into that container is I put the content type was is Jason. I'm going to give you the schema URL which points to the schema to the our actual schema for that event. So these are the first two steps. Then I go and give it an event ID. That's the literal event ID that I'm just pulling up from that event. So it's I'm using the event ID as the event gave it to me, and I also pull out the event time. Next, the event has a type and explain what that what the type is effectively. Every event so this is a second discriminator that I really don't want to talk about at this moment, but that tells you effectively what what kind of event that is within the topics let's scroll up let's skip this. And then now I'm picking now I'm picking a topic and picking a topic basically here means that I'm now picking from a few candidates. Right. What I think what the right resource type is and I'll make a discussion so for your storage for your storage problem. Right. So the topic really is the storage account and in that storage account of folder. So we would model. So in our world we would model this as subscriptions good resource groups my resource group provider storage account name slash folder. And then we had the topic name for for a storage account because we have a global resource graph in Microsoft and the global and in Azure and that global resource graph, you can go and cut a path right to a storage account and the folder in that storage account and that's what that would be. And that's kind of what I lay out here. So here in specifically I pick the the fully qualified path to the specific resource that's how I picked the top. So the topic is what you what you're what you're interested in right in a course grain fashion. So this could be a storage account. It could be a VM. It could be like all all of our 200 services that we have in Azure. Every single one of them has a recent is mapped into this resource graph and you basically pick a pick a place in that resource graph that can go in the middle that that is the model that we have. If you go down there's then a notion of a and I'm mapping in the subject. Because I need to know, for instance, in that context, exactly what is that event about so here in this case. And I wrote this down the alert and I'm subscribing for alerts from a particular VM. But or sorry, I'm actually from a from a VM slot, a runtime slot for a classic compute is instance. But I'm now getting an event that is about that resource and the subject is telling me exactly what machine in what slot is actually causing that alarm. So I'm interested in general in all the events that are flowing out of the the VM host. The event host is composed of multiple slots. In which maybe multiple roles. And so I want to catch all of those. And so I'm getting the information about which exact slot and which exact role this is about in the subject field. That's the mapping that I did for something that has nothing to do with an eventing system, but really is a real example and then if you scroll down, I did the same thing for AWS cloud trail. Where I did I take a cloud trail event as it is, and then did this containment mapping thing here as well. The same same principle, but took a, and I use this, I don't use substitute source for topic I literally use the source term as the for the top for the topic field. So here, the topic is. So this is about easy to it's about easy to Amazon AWS US East to and that's my easy to slot. The subject is the in the particular instance. It's the event type is soft instances or the instances that stopped so that's easy I can understand that without having to parse anything extra. And I took from software AG from velocity from an IT platform. A simple event, and that's the door sensor was triggered and not that in the exact same way. Again, I have the source source here is much simpler in the scope of the system because it's literally just an object. That's what they have they have named and numbered objects in the scope of their system. So that's what the topic would be. The event type is the sense that the door sensor event, and I don't even need to have a subject in this case. So the subject is something that's optional so I mapped this all out. Because that's just how messaging systems use those fields the subject is something that you sometimes need and sometimes don't because you sometimes need to have a further qualification that you can go in this patch on. In some instances, whether the context is smaller you don't in instances where the context is larger you do. And topic is the general model for how you map the resource graph effectively, or the topic graph in general a graph that you are interested in subscribing on to. So I think my. You talked early on about having. See if I can find it. So being able to pick a topic. You discussed here. Yeah. And then when you, when you were talking about the AWS use case, you said that the topic was just a source. Here. Right. And so how do you see the. As you as you're talking about wanting a topic attribute. How do you see that actually mapping. Are you just changing the name. I mean, where you have source there are you really saying we should be using the term that the keyword topic. Yeah, so this is, well, we actually wait. So I, and not only that changed the name I also changed the definition. So I've been using source here, because this, this, this issue predates my PR for changing the name to topic. That's the only reason. I wanted to refer to a term in the spec. Right. And that's why, but, but I think so source doesn't make sense to me as a term. Because in, in current in, in contemporary pub sub usage, as well as most of the eventing system that I've been confronted with the real source plays much of a role than the context you care about. And if you if the, the, the messaging protocol, like for instance, aim to pee as a messaging protocol has no notion of from with good reason because the problem is that data, where data comes from turns out to be enormously complicated. Typically applications there's an application at the application layer above that you have a fairly complicated complicated notion of data provenance with because that is if you build sophisticated systems, because that includes the, the identity under which the process runs, it might include the person who was operating that terminal. It might include someone who gave permit second permission for that particular operation. I mean it's, it's provenance is really, really complicated. And that's why most of the generic infrastructure folks just punt on that problem and just and punt that up to the app. Hey, Clemens, can I ask a clarifying question because I think if I understand this I actually really like the distinction here. Um, so the idea if I had a really like I'm going to create a really simple metaphor here like if I have to deliver a letter to you, and I can't reach you. I'm going to hand it to Mark and Mark is going to hand it to Kathy and Kathy is going to hand it to you. Ultimately the topic of that letter has never changed, but what presents some source of confusion is the source field because the source field when Clemens receives the message is Kathy, though actually there's a chain of sources along the way, which actually have nothing to do with the content or metadata related to the, you know, the message being the envelope that to be delivered to Clemens. So the idea of a topic here ultimately is a client to me a much more clear statement of as a consumer, you know, you are receiving some amount of information you don't care how it got to you. Right, you really care about the topic of what it is what what's it describes is that kind of what you're going for here. That is that is exactly what it is. So if you are care. So, so what you, you always need to look at this from the consumer perspective. You're, if you're interested in football results, right, as a real time delivered event driven thing. You never care about who typed in the football results, like at all. What you don't care about is the football results, which means you will be interested in a league, and you may be interested in the team, and then you may be interested in a game. But how that data was captured and how that data goes put into the system you don't care. And that's something that is doesn't matter and most use cases, most real use cases that we see are just like that where this actual number of events matters very little, but the context from which those events were sent or on on whose behalf that those events were sent is what matters and that's typically directly reflected in the topic. So if we can go and switch back to the to the actual PR it will be helpful. Yeah, so I think that's to take that I actually really like this distinction quite a bit on my question for you actually in some of the examples you've listed like we have like robots slash drive. I think what you're and correct me if I'm wrong here is robot and identifier because I so I have a little bit of confusion here right like USA Alaska Juno is very clearly country state city right like it's very US specific like that wouldn't look for something like Japan right where it'd be like country prefecture right like something along those lines on to really what you have here is it's robots slash robot ID slash drives right slash yeah slash temperature right so that's where my little bit confusion in here where you know if I were thinking about Kathy's example which is let's say like a you know I put an object into an S3 bucket. Really what that looks like is slash namespace slash namespace ID slash bucket slash bucket ID slash objects and maybe the subject is the file path of the you're you're exactly right so and that's the distinction that's the distinction that is really that really matters here. Sure, so the only thing I'd ask is maybe to clarify a little bit like as a consumer if I care about all of the events related to robot with robot ID. I'm going to just basically match on anything that's slash robots slash robot ID slash star right. I'm going to clarify that. But that's what that's the only thing I was going to say.  I'll clarify that Stanley when you stated that you you commented that namespace should be part of the topic. Was that like the more logical so whether the like the actual literal namespace right that indicates like if I were to go look at you know I want to go hit a describe API for slash namespaces slash namespace ID. Right I think that's what Clements is trying to say these are like not not generic or these are not abstract URIs these are actually concrete URIs. Yes, so there will be well they can be whatever you like whatever you want in this one I'm I'm composing a concrete URI for my example. Correct yes and that's what you would typically do. So you would typically go and have in a so as they say in patent speak in an embodiment of this. I will have a some kind of a structured identifier a URI that will this is why I think did I read this in here I think it should be a URI and I and I write this should be a URI specifically because I'm keen on having the structure the structuring qualities of URI in here and so and if we relative or absolute URI but I want to have the the structure qualities of your eyes. So you will have a yeah we'll have some the event will be about some context this the context can typically be expressed in some form of graph. And or being a location in some graph and that's true for all the things that are listed in here and the example that you did you just listed because the buckets clearly is part of the resource graph of AWS. You can go and formulate a path through that graph that hit that leads you to that particular bucket. In some other in all the existing eventing infrastructure that you that you will find or most existing eventing infrastructure that you will find effectively all the everybody who built something on an off the shelf open source message message broker or on top of Kafka will find a concept that maps to this. You pick a topic string topic string the topic string originates from a context in your application and typically based on some kind of an object that is in your context path. And that's what you're choosing and we have inside of that context that you're choosing which may be bigger or smaller. You're going to have another uri potentially a sub path, if you will, that then pinpoints the the thing that the event is about and that's how the split is between topic and subject. You will be interested in all the events that are coming out of that bucket. You want to learn about all the files that have just been created, because you want to go and download the jpegs, and you want to go and then turn them into thumbnails. So that's one of our canonical examples right you you're looking at a bucket. And now you want to be informed as soon as an object is created. And then you need to learn what that path is of that object. And that's what the subject is. And the reason why you need help from the middleware of this is that bucket may be large and you may be getting hundreds of requests but you're really only interested in the ones that have the suffix dot JPG. And to do this, you need to give the middleware a generic hint what to look for and the subject field is one that you can do a longest prefix match on or you can go and do a suffix match on and you can do all kinds of matching on. And that's why the subject field as one of effectively as a promoted as a field that holds data that's promoted from the event is super useful. So this is purely for the benefit of the middleware to enable filtering on a on a portion of the contents of the event. So Clemens so so if I understand you correctly so you are so this topic is subject is for the to assist the communication between the subscriber and the no between the what's that producer event producer and even consumer for for the consumer to get the needed information right is that for that purpose. Yeah, so it's for it's for the consumer to be able to pick a subset of the events that they're interested in. Okay, so it's not asking the existing event source to change their name, or, or to add a new field in their event record, you know, add a new topic field or subject field in their record. What the publisher, the producer will affect the report that they will. So think of it as a rendezvous model. Right, where you have some place that sits in the middle between between the producer and the consumer. That is, and that can also be a piece that lives with the producer where you have the ability to go and send, send messages to a path. And then, and that's what the topic really is. And then you can go and subscribe, you can subscribe to on that path. You either subscribe to something that's further down in the path and you get fewer messages, or you can go and subscribe to the roots of that path and you get all the messages. Okay, so basically, so for the from the producer, the producer, the even producer itself does not need to change any of its record, any of its event form, I mean format to add a topic field, you're not suggesting that right. But what you saw in the example, what you saw in the example that I that I that I gave that's in the item. The process that I'm suggesting even for people who to adopt cloud events is containment that you don't change any of your of your existing data searchers at all. But you take the existing data records as you have them you stuff them into the data field of a cloud event wrapper. You take the cloud and then you take fields from your existing event and just and promote them out into the cloud event wrapper. That's exactly the process that I've been been doing. So, if you look, if you look at an example again. So look at the here, here it is. So if you scroll up once. If you scroll down, that exact AWS event is verbatim contained in the data field unchanged. So all code that depends on the structure of that event will continue to work. And all I did is I took select field select data out of that data field and promoted it up into the event into the cloud event structure. So the that source field, how do you how do you compose that from the original content. Yeah. Now, how am I asking how do you actually compose. So I took, I took the, I took the here the The event source with the data center. Can we just say, can we use the term topic instead. Yeah, that's, yeah, exactly. So it's a topic. So what I took, I took from the, from the data, and this data is obviously just a log record from, from, from AWS. I took the their generic field event source, which is the EC2 system. It's really the source. It's like the system level EC2, I took the data center and then took the account ID, and that made a reasonably an identifier that I think if I was designing that at AWS and map that into a an event flow. That's how I would design that I would say, subscribe on on EC2 on this data center and in the data center on this particular instance slot. I actually, I'm not sure whether that's actually true for that particular for cloud trail, but I think what might be useful is if you could set up a set of examples that, you know, takes a AWS is three records, you know, Azure records, just a set of different sources and compose these headers that you show here as examples. I know you've done a couple of them, but I think it would be useful if you actually use the term topic and subject that you have here. And, you know, add a few more examples so people can kind of get a big appreciation of what you're proposing here. What I'm a little worried about is that so far, even though this document has been around for three weeks, nobody has looked at it apparently. I think that that probably shows, you know, because now we have a very generic way of, you know, like topic subject, right. So, and so when you send, for example, as a consumer, if I sense, I mean, a request say I need this topic and subject with that event that producer knows what that means what. So, so how could I say okay if I need this information I'm interested in a topic or subject. Then the consumer need to understand what, you know, and that meant what that means right so that need to be well defined otherwise because there are so many different scenarios. I'm just thinking, you know, how can you show, you know, people like to use this and then to be compliant with this we can really use. So the problem I'm so the problem I'm trying to I'm facing is that there's a body of work that has been done in the messaging field realized in countless products that are have all converged on this notion. And I'm having a hard time. I'm having a hard time basically communicating the industry consensus in the messaging and eventing space that already exists. On the particular topic of having a topic with an amount of examples. Because the reality is that what we're doing in the messaging space as we're building that infrastructure is that we don't take a stance on what the structure of these topics ought to be because we intentionally leave that up to the application to go and decide how it wants to structure those things. And that turns out that turns out to be to be beneficial. So I actually intentionally don't want to be prescriptive about how that ought to be looking. Because I'm not sure that helps. So the example that I gave with the so all the examples for Azure. For instance, we'll look pretty much exactly alike. The one that I gave you that that I've worked out and specifically didn't take an event that originates from my org. We'll look exactly the same across all of the same services because we have a universal graph across the entire platform where we can identify effectively each context. And so the natural topic path for that we're using is the read effectively the resource ID for for that resource. So I can give you 100 examples but they will all look the same. Okay, maybe I think my question is, okay, for example, if I'm interested in something, how should I feel the topic. And so that the nose. Oh, okay, you feel a terminology for some some topic act. And then, and the producer knows what X means and then give me a problem. I'll tell you. Well, actually, I like the idea I think this was the request. So you've done a really awesome job Clemens kind of pulling a bunch of different examples and let's take like one thing like let's say like doing a put objects to s3 Azure object storage like Oracle object storage any of the object storage is across all the clouds right like to fire base even and just do the the mapping of that one specific use case and show how topic and subject. So I have actually have one in the if you go to if you go to the issues. I apologize I haven't read this. This is good to the issues list. And there's an HPP mapping strong in. Yeah, because that actually has one in 93. Okay. Unfortunately, I have to drop off for 10am. But I actually really love the topic subject consolidation. I would vote in favor of this. I need to drop it 10 as well. I'd say, if there's some way that we could conceptualize, you know, this discussion, be able to have like a short presentation tomorrow on the call to discuss. Here's our thinking on this and here's why we think it's the right direction. That would that would be awesome. Is that something that you could pull together? Yeah, I can, I can do that. Okay. Yeah. And, and so here and I'm actually going to adjust because I can go and edit things. I'm going to go and adjust because this also predates my PR. I'm going to edit this issue. I'm going to add the other ones to go and make a topic and then, but I would strongly encourage people to go and just write read the the bigger issue. And I wrote, there's a lot of write up and there's a lot of industry context in there with, you know, quotes from existing system or or links out actually to existing systems. There's resource collections. In fact, you show see how IBM IoT does it how Microsoft IoT does it, AWS IoT does it and basically illustrate that there's industry consensus around that around those concepts so I didn't invent those. I'm going to, I'm going to have a like two or three slides tomorrow to nail down that concept, probably with three, three to four pictures. Stay help. Yeah, that would be good. If you can give examples, say, you know, for a like just gave, you know, use as a, as example, if I need some information, how, how should I, how should the produce, I mean, the consumer feel that topic and subject. How will the producer understands that we need to define some something there for the different something there or it just by different. I don't know. This was, this was really great. Thanks everyone. Thanks. Thanks. Clemens. Are you there? Yes, I am. Yeah, so I have a further question on this. Yeah, it's good. It's good presentation. So for the issue of the correlation, correlation ID, right correlation token. So how, for example, if I, I'm interested in something for example, for I3 I'm interested in the information safety in which column of that storage right. That's what I'm interested so that I can go the topic and the subject right we can go into another level of detail in that column which file specifically I'm interested. In addition to that, I would like to know like I mentioned before, if there are multiple event sources, why is, you know, storage, but the other could be another event source could be, could be another like for example, some, let me think about it. Some notification, you know, event. Okay, it's not a storage. Okay, another notification event. But these two event might, might be, you know, all about use a burglary system. Okay, from the same house. I would like to know there's so many houses sending me all this information right I would like to know. Okay, which, you know, which storage event is, and which, you know, the simple messaging event these two events are coming from associate with the same house. How could I get that information I think we need a correlation token there. You know, I can give you I can give you an example of some real examples for that from some systems that we have built and how this is how this is working. I'll give you an example from, I'll give you an example from Halo from the game, the Xbox game. Do you know that? No, I do not know that the game. Okay. Do you play online games? Okay, not much. So, so, so those problems happen quite a bit that you need to go and correlate events that are happening from different places at the same time. Yeah, we need to correlate those events. Yeah. Yes. So the biggest the biggest problem is that you often can't tell the producer that the context in which they the events are being fired. So having having the producer go and do and give you the correlation information is often not helpful. Rather than, than doing that what typically it happens is that people use a some some middleware to go and create that correlation that happens in middleware systems like sometimes you do this with with stream analytics, where there's a temporal correlation, which means you take multiple events and and map them on top of each other, because they're temporally related and you only want to have a view over the temporal stream so use the stream analytics system for this. And sometimes you have the problem that you have multiple events from different places that need to come into one place and with and go and and seek for them separately through from with subscriptions from different systems, and then you concentrate on something like an actor system where the actor acts on behalf of the context you care about. So you have a house or something or room in a house, and then you have an actor that that acts on behalf of that. What happens in the industry right now is the concept of the digital twin and digital twins are basically these these these objects which are standing in for any arbitrary context and often they they are reflective of factory floors or particular and most of what they do is basically they go and concentrate events from from certain sources, they typically will not do that though based on a single identifier that everybody knows, but they rather will do this from from different from different organizations because also those many of those events are also emitted from legacy systems that don't know about any of those things so so setting up a correlation field per se that all the producers need to go and set is something that I don't see as common enough in in factual usage that I would put that into the standard, but it's obviously easy for you like if you say that's the way we want to go. It's obviously easy for you to put, you know, a correlation ID into every Huawei event which flows in through the cloud event infrastructure. But you really have something like that. I see you've got a thing called a resource group, and you talk about it's a scoping construct that would, you know, fence or group up a number of different resources that belong to a specific solution. Doesn't that mean what you're at we're talking about here we're really saying we want these resources to be identified as a group. And that would map that in that case that would then map to the topic concept. Yeah, so so no okay so you just mentioned I agree with you that the correlation. Ask every event producer to add a correlation ID there it's not we can that's one way of doing but might not you know every part event producer would like to do that right. Okay, so I think you know that's of course if you know the event source can put a correlation ID there that's good. Okay, that's I agree with you that's what we're doing but might not be you know everyone will follow that another way is I think you know in the event. So the eventually, for example, for that burglary system right assume that the motion detector and the door open detector when the information they send out.  You know just different vendors, for example, the sensor different sensor vendors and different you know video camera vendors they might put into, you know, different places we cannot force them to say you have to put, you know, this ID what it's called or where you should put it, it's hard to force everyone, but they must be there. So if we can have you know in the, I'm thinking you know if we can define a way to, you know, we do not know where it is put right, but the producer knows, for example, they if they put a house number or high IP address to identify that house. Okay, whatever, whatever that thing, they know where they put it right because their equipment put that, but if they let us know where they put it. So there is that information we can, you know, put into the specs say okay. So I have a proposal for you that information. I have a proposal for you because I think that that problem that you're just illustrating is is actually solvable within the scope of what we discussed today. Because, because you just talked about because you just you just you just actually led with the fact that there's a there's a structure. So there is houses, there's buildings you care about. And each house hasn't hasn't has a unique ID. But let's say you have, you have country organizations, each country organizations issues house IDs. Right. And so, and in these houses interesting stuff that you're interested in so you're making a topic in your infrastructure in the way infrastructure that is that that has a number slash a topic that is called slash d e slash one, which is my house. Okay, and all the all the all the objects that are sitting in my house that are talking with your system will now publish their events to that topic slash the slash one, which now gives you a perfect place where you can go pick up all those events, because you only need to go and subscribe to slash the slash one, and you're getting all the events from my house and then you can in the subject is then the identifier of the actual sensor that gives you the information. Yeah. That's what that's what so that's how that solves your problem, your problem is solved by creating a a broad scope that you can go and subscribe on and it would not be as simple as it would likely not be as simple as slash slash ID but something that's a little bit more sophisticated. Yeah, yeah, yeah, yeah, yeah, I think we are along the same, you know, so I think you know. So we were like safe. But the thing is that when I, when I. So, actually, it's not like, you know, on the produce the consumer will send a message to the, to the producer say, okay, give me this information. I would like to say, okay, let the consume, let the producer feeling a information of that pass say okay, what is, you know, the correlation token where my car, you know, the house number is located. I receive that message right on that.  I can just, you know, based on that, I can just extract that information for example, if it's a say okay, it's a, it's a house number. That's a, that's a house number is unique.  Of course, the value could be, you know, comments house, that could be, you know, Louis house address or Kansas house address, the value varies. But I know what string I need to search. I just search, you know, house address. Oh, that's unique. And then for another use case, it could be, you know, I don't know. Oh, some like travel request ID. So I search travel request ID. Of course, the value could all be different. Right. Different people make travel request.  So the, the, you have a graph that represents all the buildings that you care about. Okay, so all that. So you have, you have, let's say you have countries, and you have in those countries you have building IDs. Okay, you are no interested in your solution from all events emitted from one building and you want to have them in real time. Right. That's what this is about here. Right. It's about getting at that information real fast and being able to get some targeted messages towards you. Right. Just as a, just as a, as a reference number. We currently do 1.5 trillion messages a day. Just in terms of events. So you have to be able to get to get to a few events very specifically. So you need to go able to filter on what you're looking for here. So what you're looking for here is a bit is the ability for 20 sensors which are in one house. Exactly. And to be correlated together. Exactly. You can get the events for all of those 20 with effectively from one pipe. Right. Yep. Okay. So that's what the topic, so topic model allows you to do this because all of your, all of your resources exist on a graph. The graph has the first level and our graph that we're just talking about has two levels. First level of the graph is countries. The second level of the graph is identifiers for individual houses. And if you are interested in your system and events that are coming from my house specifically, you walk up to the topic and you say, I'm interested in everything that comes out of Clemens house slash D e slash one. And that will give you and that will give you all the events for all the devices what you need to do on the producer side, which means in the devices, you need to go and configure them to say, you're going to publish all of your events on this topic. You are sending to slash D e slash one. And once they all do this, then you have that correlation automatically. So, so when I send that message from the. Okay, the top pick. Okay. Do I need to space it so you say, as a consumer, the consumer should know what is a correlation key. The consumer knows the consumer knows the context it's interested in. It knows that it wants events from that house. It doesn't. In the first level, it actually doesn't even care what devices are in that house. It just knows that it needs to observe everything that's in that house that wants to talk to it. Yes, also, okay, let me explain a little bit. Okay, the scenario different. Okay, so I'm a service platform. Okay. So for service platform, it's going to handle so many different events, so many different uses scenario, right. So why use the scenario is interested in the consumer, the burglar system, the house. Okay, but there are many other scenarios. So as a service platform. So I'm the service platform. I do not know whether I'm interested because I do not really. I'm not service platform is not the application developer. When I say application, I mean the burglary system. Okay, developer. I'm not super the system developer. I'm just a middleware platform that you know, receive the event I routed to your function to your application, the burglary detection function, right. So, so as a service platform, I do not know whether I'm interested in, you know, a house, or I'm interested in the travel request ID, I have no idea. Yes, but what you know, what you know is, is that someone can can publish to a to a path, and you can provide them with everything that matches certain prefix of that path. Exactly. Okay, so, okay, so I would need the application developer, which is a burglary detection function application developer. I need him to let to tell my service platform say, Oh, I'm interested in, you know, in this house. So let me know what he is interested in here. Okay, what's the correlation token, his application needs. What, what the, what the, what the, you have a, you have a, the topic is a path. And you're always interested in either that exact path or prefix of that path. That way, there's no, there's no correlation token. When I say correlation token, so, so let me, when I say correlation token, that token can be a path. Okay, good. Okay, I'm just using that as the, you know, what I need. Okay, I'm not saying there should be a specific, you know, correlation token field there, of course, if the producer putting that that's fine. But it's just a string that string could be a URL, who could be like in JSON format could be a path identifier. Okay. And so my, what I'm saying, what I'm saying is, and my battery is just about to die. So, I have to switch computers this morning. Okay. Is, and I have no power here. So I have to hang up the, what I'm saying is that your notion of a correlation token is exactly what I mean with top with topic. Okay, so, so that's good. So let's see just, okay, let me remember.  So that's why I need a field, I need someone, you know, to tell the, the service platform need the function developer tell it what he needs. And then I can just, you know, when I get the event data, I can extract, you know, that message based on the specification of that token, you know, it's travel ID or it's what, and then, you know, to extract the value, right. If you say it's a house, I'm going to try the house number, or house address. But as the middle, as the middleware, you are just doing, as the middleware, you can ignore all the, all the specifics. Yeah, whatever he tells me. Yeah, it's a string or it's just a string, it can be your ID or it can be a path identifier.  But I would like that to be in this. So let me, I will try to make that a little clearer for tomorrow. Yeah, yeah, so let's just say, you know, you can use a string or use URI, but, you know, correlation token is the meaning, is what it means. Otherwise, if we just say topic, you know, the function developer doesn't know what's that topic, what topic you need. But it turns out a lot of people know what a topic is. The topic has to be specific, right? There are many, many semantics of topic. So one of the topic will be a correlation token. That's my point. Yeah, you can say the topic will be other things you need. Yeah, I understand where you're coming from. And I think your notion of a correlation token is perfectly satisfied by the concept of the topic that we have. So besides URI, I think let's just say it could be a path that I can file, because sometimes it's in JSON format, let's extend that. Otherwise, if we just say it's a URI, you know, in some cases. URI is efficient. URI covers pretty much everything. Okay, URI is good, but we give some example. And then because most companies use it's JSON, yeah, let's just, yeah, use that. Okay, that's good. Maybe we can discuss a little bit further, have a sometime sorting this out. I mean, how to write this up. Yeah. Okay, very good. Hang up. Have a good day. You too. Thank you.


Alright, in this video, I'm going to share with you a reality-shifting technique that works every time. Now, can that be possible? Is that possible? We'll see. So, firstly, we just need to remind ourselves. You should have remembered this from one of my previous videos, unless you just didn't watch that. So, the holographic reality is this idea that every part of our existence, every cell in our body is intrinsically connected to every other cell and every other part of the entire universe. I know that sounds like a lot to take in and, you know, you might think that sounds like nonsense, but honestly, this stuff has been proven. If you look into quantum mechanics, non-locality of electrons and protons, this stuff has been shown through modern science to be real. And the modern science really just kind of confirms and corroborates the ancient knowledge because they knew this 5,000 years ago. You know, and if you look into the any of the ancient texts, dead tea scrolls, the Gnostic Gospel, all of this stuff, they knew this stuff a long time before what we would say as modern science has caught up with that. So, and by the way, if you want to kind of fast track this, I have a free video training. No catch. Okay, you just click the link in the description. You'll be able to learn how to raise your vibrations, shift, manifest your dream reality and kind of do all of this effortlessly. So go and check that out if you want to have a look at that later. And let's just get right into it. So what is this technique that can help you shift every single time? Well, it's to do with the language of what we what I'm going to call the divine matrix. So if you imagine that everything around us is a holographic, bioelectrical matrix, a grid of energy and mirrors. And and there's been many different explanations of this throughout history, right? A couple of books I find interesting. One is the holographic universe, which explains how things are kind of like a fractal and a mirror. And there's some others as well. I'll put some links in the description to these books. But really, you just need to understand that everything we're seeing in the in what we call the physical 3d reality is just an echo, kind of like a the surface effect of something that's happening at a much deeper level. Or and I guess you could say deeper or higher, you know, a level different to this one. And when you learn how to change things in that upper realm in that higher dimension, let's say, then changing things in this physical realm becomes very easy. It becomes effortless. You can manage. And this is the whole kind of origin of these concepts like the law of attraction, manifestation, you know, when you learn how to actually change things in the higher realm, they easily manifest in the lower realm. And there's one key way they do this one kind of language and that is emotions. So emotions are very powerful. I mean, we obviously know this through our own experience, right? When you experience an emotion, it takes over your whole body and mind and you just feel that emotion very strongly.  But usually, when you invoke a positive emotion, so when imagine that, like I said, the last time you you achieved something really spectacular, you know, or you were really happy or excited, just the feeling of that emotion takes over your whole body and you kind of vibrate, you know, you kind of feel buzzed. I mean, people literally say this, they say I felt buzzed. I was buzzing with excitement, because you're literally vibrating at an energetic level. And that's really kind of you generating energy or power. But most people, what they do is they'll feel that emotion, let's say excitement, or even anger, let's say, and they'll just let it kind of just be there vibrating without really doing anything. It's kind of like you're you're turning on your battery, your energy source, and just leaving it doing nothing. You're not directing it into anything, you're not using it to get what you want, you know, frankly. So there's a very easy way of doing this. So what you need to do is firstly get used to the ability of generating an emotion like practice actually making yourself feel excited or happy.  Okay, there's loads of different ways of generating, maybe I'll make another video about that. Generating an emotion you want to have. And one of the most powerful things you can do is to learn how to actually decide what emotion to feel. Because many people are just kind of reactionary, they just react to things that happen to them and then they, you know, get swept all around in life and they don't really have any direction. It's much better, it's much smarter, I would say, to decide what emotions you want to feel. So learn how to generate a positive emotion and then attach that to visualizing what you want to have. This is the language of the divine matrix, this is the way people manifest things. And if you look into law of attraction circles and, you know, things like the secret or there's various different explanations of this. Whenever you, whenever someone's talking about how they achieved something massive, and this is really common in like athletes or celebrities or people who have achieved like a really high level of success, they, in interviews or in biographies, they will always say that they first saw it in their mind and then they visualized it every single day. And then they attached an emotion to it. They emotionally visualized exactly how it felt to get that result, exactly how each step of the process would feel, what they would be doing. And then they just visualized it and it kind of become, became a part of them. And then ultimately it manifested, they shifted, they changed from one reality to another.  But the change, the emotional and energetic change can happen instantly.  So let's say if you, I can't think of an example now, let's say if you want to be able to do 100 pull-ups in a row, okay? Obviously the story you have at the moment is, I can barely do one pull-up. Am I ever going to get to do 100? And that's the story you tell yourself, which reinforces your beliefs, your subconscious beliefs and then your body kind of acts to make that become true. So every time you do a pull-up, you're, before you even start, before you even put your hands on the pull-up bar, you're subconsciously telling yourself, okay, here we go, we're going to try and do a pull-up. And previously we've failed after one. So this is going to be a tough time. So you're kind of setting yourself, setting yourself up to fail before you even touch the bar. And this is really why visualization is so powerful.  Like how does it feel? And visualize it kind of being effortless and easy. Now obviously it won't make a difference instantly, but the mental and energetic change does happen instantly. And then all you need to do is keep doing that, keep putting yourself into that emotional, energetic state. And then over time, before you know it, you have the result. You can do that thing. You've shifted into that new reality. Now of course this is a bit of a different take on reality shifting, and I understand that, but I just wanted to kind of get this concept across because the same thing applies to shifting.  So if you're having trouble with that or manifesting or really anything, focus on the emotions because that's really literally where it all starts. The emotions are kind of the fuel that allows you to change the divine holographic matrix. So I hope this makes sense. I'd love to hear your comments about this. And don't go yet because you probably haven't checked out the free superhuman training. This is kind of like a free video training. The link is right there in the description. It should be the first thing you see actually if you just scroll down to be the first link you see. And that will show you my three step process for how to become like a superhuman. And this is using a concept that I call spiritual biohacking. This is something that I coined about a year ago. It was really just a way of explaining how I put all these things together and create a system that allows you to change your vibrations and become the person you want to be to manifest the reality you actually want to experience. So check that out and comment what you think about this. Have you tried this?


For the first full proper video of 2024, I wanted to do something really special. However, 2023 ended with a big surprise. I shared Elixir, the animated series and story that I've been working on since I was a kid. Now, this video is a bit of a follow-up to that, and I feel it's important to make this video now so that we don't lose the momentum fully before letting it go. If you haven't seen Elixir yet and you're curious about what it is, please watch that video first and then come back here and watch this one next. You know, originally I thought that the way that Elixir would come into being would be like this. We would keep making spirit science, build up spirit studios, then we would write the book for Elixir, then we would remake the animated series and then maybe one day we would do a big live action mega movie. But it dawned on me recently that this might not be the actual highest path to take. If Elixir was something that people were really interested in and wanted to see developed over this year, there's no reason why we couldn't publish Elixir chapter 5, 6, 7 and continue the story picking up from where we had left off all those years ago, but bridging it and developing it into the story that it is today. And to be honest, the thought is kind of tantalizing, but I don't know if this is something that you would really want to see, and that's why I'm making this video today. So I'm just gonna publish this video and then see what comes of it. You know, if it leads to the telling of the story, then that's amazing. And if there's not a lot of interest, that's okay too. There's a lot of spirit science content that I'm gonna make regardless. Now at this point, a lot of people might be wondering, why do this? Or why do this now? The idea of Elixir is actually an Elixir of life for the suffering and challenging conditions of the human consciousness as it is today. For instance, here's an image of the world map. As you can see, it's sort of shaped like a heart and the main two kingdoms that this story spirals around, Osik and Farin, represent the left brain and the right brain, both within the individual human mind as well as in society. The challenges between these two kingdoms and the great battles and conspiracies that take place also reflect the very paradoxical duality between the masculine and the feminine energy within human consciousness. It's through the telling of this story that we unravel those paradoxes and actually create a journey for people into the reconciliation and healing of these divine truths. The story then becomes a metaphor and a symbol and an idea that can ultimately be for the healing of the world. This is why I'm so compelled to do this, and ever since this year began, Spirit has been moving within me to bring this story to the world. It should be understood, the telling of the Elixir story is not just a one and done thing. It's not just this animated series, this is just stage one in a really big road map. We perceive this story and the world that it takes place in to be so meaningful and so rich with wisdom and potent experiences that we could see this evolving over time, not just into the book or the movie like we discussed, but even a video game or a virtual reality experience. A place that you could go like an online MMORPG, but one designed fundamentally for the conscious awakening and evolution of humanity. But I have to be honest, it's such a big, brand new, different kind of thing than anything that we've put out before that it's really taken some time to figure out how to share all this with you and get the ball rolling, but I think we've found a way. There's a few stages in the launch of Elixir and bringing this to the world, but the first one is that we've created something called Elixir Founding Members. This is a private membership space that is designed as a collaborative environment for people who are interested in supporting the telling of this story. Inside the space is a bunch of world building material, the first section of the plot, concept art, and even commentaries and more behind-the-scenes content. We also have a community space featuring a feed, a chat, community challenges, as well as a space for doing live streams in the future. After this, and depending on the interest, we intend to launch a Patreon to help the continuation and support of the telling of this story. But we're going to do this in stages, one thing at a time, because we know that this is the planting of some very, very big seeds. If this sounds exciting to you and you want to be a part of this project, please use the link in the description to sign up today. Over the next week or so, we do have a few more pieces of content about the world of Elixir that we're looking forward to sharing, along with an upcoming Spirit Science 14 and some other announcements regarding Spiritverse and Spirit Mysteries. Please stay tuned and thank you so much for watching. As always, it's an honor to share in this journey with you.


So what if I wanted to attempt to remove a node that doesn't exist? So in our case, I wanted to remove, say for example, 46. Well, I would traverse my nodes just like before, and I would see that 45 has no 46. So in this case, I would use whatever I accessed before, just like I did when I was dealing with a lookup that had a non-existent node, I would go to sort of whatever accessed that beforehand. And in this case, I would work off of my 45. Now, I don't remove 45 because, again, I wanted to remove 46. I just use 45 because I still need to display this as my new root node. Well, that means we happen to have some x, some y, and some z. Now, you notice that in this situation, we are dealing with a zig-zag structure. And as a result, we use trinode restructuring. Restructuring. So as a result, just like always, we need to establish what my a, b, and c are, my a, my b, and my c. And as always, these are working off of an in-order proceeding. So I only worry about my x, y, and z. So as we've seen in the past, since I'm not dealing with any left child, I don't work off of that left, and then I access myself. So in this case, I would access z. Then I would need to say, well, who am I accessing next? I don't access y next because even though it is my right child, I see that it has some left children. So I would want to go down and access them first. And in this case, we happen to see that that's my x, and then we see that I am left with a y. So just like we've done in the past, we need to establish, given this structure, who gets my t1, my t2, my t3, and my t4 nodes. So just to kind of draw them back out, I see that t1 is coming from z's left side, t1. t2 is coming from x's left side. t3 is coming from x's right side. And then finally, t4 is coming from whatever y's right side was. And if we remember what I want to do with this, I want to take b, whatever node happens to be b, and give it c and a as its next available children. The reason why this is important is, again, a will get t1 and then t2, and c will get t3 and t4. No, that's a little tiny there, so squint real good. So in this case, I would take this structure, and again, even though 46 was what I was worrying about, I never had a 46, so I worked off of what would have been accessed beforehand. And in this case, we see it's that 45, so 45 gets to become the new root node. My a would happen to be my z, and that's the left node. So 30 would come over to the left. My right node would be whatever c was, which was y, which is 50. And then I would inherit t1. t1 would come over to the left side of whatever z was. t1 happens to be 25 and 20. Now there happens to be no t2 or t3, so we are kind of looking out there. I wouldn't give anything to 30 and I wouldn't give anything to 50, but I still would give 50 t4. And so in this case, 75 would be the right child. Let me make that a little bigger. 75, then 80, and finally, 76 and 90.


Er ffordd, fel y gallwch chi'n amdod i'n ei dda i'n gwybod fel y dweud o'i ei ddoch bwyd yn byw'r gwybod i gyd, ac yn ymdindwch, i'n rhan o'n effaith mewn ni ddodio, felly oedd James i sylfa arall felly peirion.  Wrth gwrs, nid oeddwn i ddim yn ymlaen, ond mae'r ymdweud yng nghymru, o'r ddau cyfrifedol, o'r cyfrifedol, o'r cyfrifedol, o'r cyfrifedol. Rwy'n cael ei gweithio'r ddau yn gwneud eich ddau'r rolygiadau eich ddau? Rwy'n cael ei ddau'r ddau'r cyfrifedol, ac mae'n dweud. Rwy'n cael ei gweithio. yr ydych yn credu bod yn gweld ddechrau.   Agech y modd yn mynd i ddweud o ddweud sy'n gweithio i ddweud, deall i ddweud i'r wazin er mwyn o ddweud. So ydych yn gwneud o gynnwys, ydych i'ch gweithio a gweithio a gweithio i gweithio, y dyfodol y gweithio y tîm sy'n gyfoeth oedd yn ddeud. Yn ddych chi'n gwybod wedi'u'i gwahoddiad i'ch gweithio'n gweithio, yw dyfodol i gweithio a'r gynghwyl yn gweithio i'ch gweithio i gweithio'n gweithio. Mae'r ceisio cyflwyno cyhoeddiadau yn gwneud o'ch gweithio i'ch gweithio i gweithio, fel y cwmhysiwngau cyllidau. A y Ddech chi'n gyfaelio cyffin iawn, byddwn yn amlwg o theid amser o cynhyrch yng ngwyfyr ddech chi'n ymgyrch, ac y troheu, dylai, cael ei wneud yn y rhoi wedi ei wneud yn mynd i adonbwy. Rydyn ni'n gafodd ar hyn o dystopion ac eu dypion o sylfaethol, a'n gydag, cael siŵn i ni i ni'n gydag pethau yn ymchwilol. Rydyn ni'n gweithio'n cael hwn o dŷch ymweld maen nhw'n cyfais, fel yr ym ранol i niutraffu gyda'n hefyd, mae'r iawn wedi'i ddweud ymlaen i'n meddwl sy'n digwydd. Fy wnaeth yma'r ffordd iawn, rydyn ni'n gwneud ar y Cyлиn Llywodraeth, a rydyn ni'n meddwl am dynnu'n meddwl ar y 5th bydd, ond rydyn ni'n meddwl yma, rydyn ni'n meddwl yw'r eich gweithio, rydyn ni'n meddwl i'r ffordd iawn, ar gyfer gweld, ond rydyn ni'n meddwl i'r ffordd iawn, a'r mynd i'r ffordd iawn i'r modda i'r bydd. wedi bod yn llawer byddai'n grifiannym o'r byw peth yn allan fod lle i fyw'r hunain a'r unig byddai, felly mae'n bwysig yn rhan o'r byw peth eich rhan o'r byw peth yn ll yog o'r beth o'r protected i'r Fyllty. El ehol o'r pwysig yn fwy o theriannol, o'r byw peth, a'r bufysig maen nhw'n llwg yn gweithio i'r byw. Ac mae'n gyflaen i'r hwn eich bod yn saithio'n ddweud i'r hynny am ffasgau hefyd. Ond yn dduod ychydig iawn, bydd eich gweithio'n gweithio'n ddweud i'ch bod gwerthu'n fanyddol ac iddo hon yn ochr, fy Cynghwil cyntaf, i'r cydechrau. Felly ond y fkerch, fyddai'r sech 320. A'r bai gael eich tunnag yw'r gwaith, rwynt mynd i'r gweithio cerdd mwy gynorth. Mae'n ffordd, mae'n ddweud sy'n ddweud yn hollwch. Mae'n gofyn ar y gallwn, yn cael ei ddweud yn ddweud. Yn cael y gallwch whenidau, ac mae'r parwysig, mae'n gwirionedd, mae'n gwirionedd. Mae hyn yn ystod o'r ddweud. Mae hynny'n gwirionedd yn cael ei ddweud. Mae'n gwirionedd yn hollwch yn mynd o'r gweithio o ffyrdd, ac mae'n ddweud i'r gwirionedd yn hollwch o'r ddweud. Mae'n ddweud i'r ddweud yn hollwch. ond ond y casRIF wneud hynny i gael ffordd DAF-Lion gyda gysylltu'i gwahanol. Dwi'n meddwl i'r amser sy'n meddwl i'r meddwl cyfrifiad. Felly ar y ledlod, yefyd, yn paraigwau. Mae'n meddwl i'r meddwl i mewn bod yn mynd yn rhaniaidd. Mae'r meddwl i'r meddwl i'r meddwl i'r meddwl i gwynedd a'r meddwl yn gofyn oedd wedi bod drwy'n rhaniaidd.  Felly, ac yn ymwylo i gweithio eich ffordd? if it's done well, you don't even notice it. It's hard to recognise it because it's out of sight and out of mind. And maintenance isn't just as cool as making new things. If you make new things, you get attention, you stand on stages giving talks, but keeping stuff running, cleaning equipment, looking after communities, be that online or offline, looking after relationships, repairing equipment. All these things tend not to get you much attention, much interest, Even though makers do need the things that they use to be maintained as well. All of our businesses and organisational forms and investment tend to be biased towards making new stuff. It's much easier to say, I'm going to make a business to make new things and sell them than it is to say, I'm going to have a business that's going to look after stuff and care for it and keep it in use. Starting a new innovation project in a company with a high growth business model is really straightforward. But starting a social enterprise or co-op that might be building for the long term, creating something that we looked after for five years or ten years is much harder. We do have some encouraging things, there are more commons models, things like creative commons and digital content that are starting to make it easier to think about business models that sustain stuff, but it's still a little bit more challenging than you'd think. And there's also something about culture. We don't value maintenance like we do invention. We don't recognise maintainers like we do makers. And think of all the different places where maintenance happens in our world, repairing infrastructure, fixing stuff that breaks, finding places where older items might still be valued even if they're not valued where they are now, matching bits of broken goods that are needed for spares elsewhere and stewarding shared resources so that communities can benefit from them. We've got to really design for that and we don't always do that in our culture today. We think innovation is like magic light bulb moments, but technology is not the same as innovation.  We're very preoccupied with novelty, but it fails to account for the support of technologies that are in widespread use. And it obscures how many of the things around us are really old. So in his book Shock of the Old from 2007, the historian David Edgerton talks about technology and use and finds that a lot of common objects like electric fans and many bits that you might find in cars have been unchanged for a century or more. When you think about that sort of broader perspective, you can really see that maintenance is out there even for tech stuff. It's just we don't think about it. We think that innovation stories are white guys and garages in California, but people around the world are working with technology, different technologies, and they're thinking about them in different ways. They're thinking not just about production but about repair and reuse. So while novel objects tend to preoccupy the most privileged parts of society, folks in other places who are less privileged are thinking less about novelty and more about keeping essential things running. And the most remarkable tales of cunning and effort and care in maintaining technologies are happening elsewhere, perhaps not so much in our world. And we tend to forget infrastructure as well. Infrastructure is this really unglamorous term, the kind of word that would have vanished from our dictionaries longer ago if it wasn't so socially important. But if we talk about infrastructure as more, we move away from the technical matters, the deeper questions, the moral implications. Some of you were in the ethical software talk earlier talking about how civil engineering developed greater practices of ethics after things like bridges failed. That's something which we're still thinking about now in society. Train crashes, bridge failures, urban flooding, these are manifestations of things that are not working right in our infrastructure because we don't necessarily think about the ongoing bits of stuff we need. Instead, we get distracted by flashy new things. And whether we're thinking about infrastructure or all technology rather than new things, it reminds us of all of the work that keeps the world going every day. The central fact of our very industrial civilization is labour. It's work, and a lot of that labour falls into maintenance. It's not innovation labour, and innovators and inventors are a tiny slice of the world, maybe 1%. So we need to think about maintenance and distribution as well. And another important part of technological labour, if we're going to think about tech which we tend to do at EMF, is the people who are using the product. They are also labouring. I mean, it's quite different from the labour we see elsewhere. So, a quick spin through a variety of things that we need to maintain today because nothing comes without its world. This is from Donna Haraway. No object comes without the need to maintain it. And so we need to think about the life cycle of the object of how we look after it throughout. Some of the objects we might think about, community spaces like maker spaces, this is Cambridge makespace, community assets. I've grabbed a slide of open benches because I know there was a lightning talk about it earlier, but things like benches, someone has to look after them to keep them maintained, keep them all working. Communities themselves need maintenance. Online or offline, communities don't just happen. People don't just thrive together without some effort. And so, for instance, reddit moderators play a huge role in making sure that reddit, which we can debate how well they do it in different subreddits, but it's a labour that has to get done. It's maintaining the community. Open source needs maintenance too. I picked open SSL as a classic example of an open source project where there weren't actually many people maintaining it and we didn't realise until everything went wrong with Heartbleed and then suddenly we think, wow, I need to be thinking more about this. Someone has to look after this stuff. Standards, something else you may not think needs maintaining. We tend to think about tech standards like Wi-Fi 802.11, but there's also small standards that come in all parts of our lives. The standard sizes for screws or the standard sizes for envelopes that we've got here. Standards are critical. They help us to have confidence in the world around us for food or goods or whatever. The internet. I just put this here because it's a really big question. It maintains the internet. If we followed an internet packet from my phone all the way to my friend's phone in Australia, think of all the systems it goes through and what labour is being used to maintain all of those different stages all the way through that we're so dependent on. Stuff like Wikipedia. There's a lot of maintenance that goes into this, both looking after the content and keeping it organised so people can find it. And of course infrastructure, as we've talked about. It's easy to assume in a rich country like the UK or American infrastructure maintenance just happens, but if you think about the potholes you've probably encountered in your world, they're pretty bad here in the UK and in the US. Infrastructure is in a really bad state right now. The American Society of Civil Engineers has recently said that 17% of American dams, and you'll note that dams are pretty big and important bits of infrastructure, are high hazard potential due to neglect of maintenance in those dams. Our lovely developed western rich economies we're not looking after our infrastructure very good. So a few random thoughts on maintenance. Who maintains stuff? Probably more people than you think. In the computer industry there's a bit of research which is presented at the Maintainers Conference in America that software maintenance, so things like fixing bugs and distributing upgrades can account for more than 60% of the total software costs. And in one study they found 70% of engineers were actually maintaining things rather than designing new ones. Maintenance can be blue colour, we can think of mechanics and plumbers and janitors and electricians, but it can also be white colour, like the IT crowd, or white jacket maintenance, like dentists, dentists as a maintainer. And our obsession with the sort of technological novelty tends to hide all of these other forms of labour away, including things like housework. Women disproportionately keep life on track for most of us. And domestic labour has huge financial implications, but is very rarely counted in how we think about how the economy works. So in 1983, Ruth Swartz Cowan in her book More Work for Mother talks about how new technologies, like vacuum cleaners and washing machines, actually fitted into women's ceaseless labour in the home. And one of her more famous findings was that these housekeeping technologies actually increased women's labour of what length of cleanliness was acceptable, increased, so they weren't actually labour saving at all. And who pays for maintenance in open source? So something like open SSL until recently, perhaps the answer was nobody. It's being done by volunteers around the edges. But maintenance is also big business. If you're a big engineering company like General Electric or Boeing, you're making heavy investments in tools and procedures for maintaining all of the systems and machines that you use, because breakdown means a huge loss of income. And even in digital industries companies like Amazon and Netflix are actually doing a lot of maintenance as well because customers are only happy when things keep working. So you need to maintain before it breaks rather than maintaining afterwards. But it is tough to find business models for that given our focus on making things and selling them. This is a quote from a book called The True Cost of Maintenance. In places where you maintain stuff, it goes wrong. Maintenance can often look like a burden. It's a cost. It's not something that you really want to do. And the traditional approach of management is to try to trim that cost down. And we maintain things at different times. When we pause in their use we might maintain something on a regular cycle like we service our car every year. Or we maintain stuff when it breaks. So it's quite different kinds of maintenance timings like that. And how we learn to maintain is interesting too. Young farmers in America used to be trained maintenance how to look after their equipment as part of training as a farmer. And home economics classes used to teach you how to look after and repair stoves and fridges. We seem to have forgotten some of those things in more recent educational programmes. And as we said earlier things have maintained often more in poorer contexts where there's less option of getting something new. Or places where supply chains are limited so you don't have a choice. This is just a session from the academic conference in the state, which I liked, during the cycle of maintenance our different kinds of maintenance are interconnected. In this case in the world of elevators. And cost of maintenance is quite a lot. It's good. I'm just going to spin through this. And maintenance being safely critical is interesting. This is a study of mining safety which actually found that the maintainers themselves are most at risk. Those doing the work are not always helpful. If I step on to what's happening next in maintenance, I just want to share this. Juris is an ethnographer and this idea of maintenance as infrastructure or ontology can start to make a signal that maintainers are other and they are somehow inferior. But maintainers themselves have a rich culture and value in what they do which is worth thinking about. One of my favourite examples of maintenance is from Cambridge. We have a gorilla groundsman who goes around repairing benches cleaning road signs doing gorilla gardening. He's anonymous because his work is semi-legal. I assume it's he. And he's going to be talking at my event shortly. I think it's a really cool thing to do. And also just briefly digital maintenance. This is your classic XKCD. We don't maintain our digital assets. We can lose them forever which is perhaps unexpected. And finally, you can't actually maintain things forever either. Fairphone is not going to be maintaining Fairphone 1 because it just becomes impossible after a certain point. And there's been ideas about whether we should talk in advance about when we will stop maintaining things perhaps putting expiry dates on internet of things products. So I've already touched on some of the things that are making maintenance easier these days so I'll spin through this super quickly. New business models like leasing is really helpful and crowdfunding can also be a way of looking after things. This is leasing genes in case you've not seen it. It's part of a circular economy business. Make spaces and repair cafes make it easier to look after stuff. We've got greater access to tools as well for tool libraries. The average power drill in the UK is used for a total of 13 minutes in its entire lifetime so we really don't all need our own power drills so it makes sense instead to loan tools which gives greater access to more people. The internet also gives us access to information for parts for information on how to maintain things as well and it helps us co-ordinate. This is another example from Do's Liverpool where they have a somebody should system on GitHub that helps them co-ordinate volunteer maintenance of the space. So, what is next? There are many amazing individuals and projects so we're trying to maintain repair, reuse and sustain all parts of our world and they're in the public sector and the private sector and they're volunteers and they're in co-ops and collectives and too often they're invisible. So, as you're going about your world think about who's maintaining it and think about whether or not you could help them or recognise them or even just say thank you for the maintenance work that's making your life easier. I think this is a quote from Lee Vinsel who set up the Maintainers Conference in America. Innovation speak sort of worships as a change but actually why are we changing things? Why are we moving new things? Thinking about maintenance helps us talk instead about questions where we can ask more about what we want out of the technologies and the things that we're making. What do we really care about? What kind of society do we want to live in? And so, I'm organising a festival of maintenance. It's on the 22nd of September and it's going to be a celebration of those who maintain different parts of our world and how they do it. Recognising this often hidden work of maintenance, of stewardship, of custodianship of tending the things that matter. It's a whole day full of short talks and debates with a diverse range of maintainers, community managers, repairers and stewards and the people who look after them. This is a tiny fraction of our awesome range of speakers. We've got the guerrilla groundsmen coming. I don't even know who he is but I have faith he's going to show up and talk anonymously. We've got folks talking about digital maintenance. We've got folks talking about building facilities maintenance. We've got people comparing innovation and maintenance way more competently than me. All sorts of things. We're doing really lively so do check it out. There's lots of information online. We've got a couple more speakers still to announce and tickets are just £12 at the moment because we want to make sure this is an event that's accessible to the kind of people that do work in maintenance. So yeah, do come along and join us and hopefully this will be part of an ongoing dialogue where we can start to think more about the role of maintenance in our world as well as making because making is cool too but maintaining stuff is important and we should try to say thanks a little bit more often to those who maintain our world. Thank you all. Thank you very much. I need a gorilla groundsman for my garden because the current groundsman is not just not cutting it. We have time for questions if anyone has. You have no idea how bright it is up here.  Whereabouts is the festival of maintenance going to be held? It's in central London at the University of London Union which is near UCL, Bloomsbury sort of area. It's going to be a super informal day. Really chill so do come along. Any more for any more? Such a good audience, sticking out late on a Sunday. They're good to come here. This feels very virtuous coming to this talk at all when they could just be in the back. We know that most of these people maintain us from our sample at the beginning so they're all obviously interested. Cool.