Context for MQTT with the Web of Things

Webinar Overview

The data produced by the MQTT devices around us is highly valuable. We build systems to act on the data and the knowledge, and for that we need context about the data. Indeed, it is important to know whether the temperature data belongs to a sensor in my smart home, an industrial furnace, or a connected vehicle under the hood compartment.

In this talk, Ege will show how the Web of Things standards at the W3C bring context to the MQTT data around us without changing the data itself, even reducing the payload size if you want to. Additionally, you will get to see how we can onboard non-MQTT devices into MQTT systems without losing any meaning of the interactions of the device.

This will not be just a talk; you will get to see live code and interactions over an MQTT broker. So, make sure to have your MQTT clients ready!

Key Takeaways

• As more metadata is added to MQTT payloads to meet different subscriber needs, the payloads become unnecessarily large and complex. Metadata and data should be decoupled.

• The Web of Things (WoT) is a set of W3C standards that bridge different network protocols like MQTT to applications while keeping the protocols unchanged.

• A key WoT component is the Thing Description (TD), which provides metadata about a device/thing separate from the data payload. TDs contain contextual metadata.

• For MQTT, the TD specifies the broker URI, topics, operations (publish, subscribe), and MQTT-specific vocabulary from the standards.

• Using TDs separates static metadata from frequently changing data values, reducing payload sizes while providing more context about devices.

• Manufacturers can provide TDs describing their devices, or TDs can be community-generated.

• TDs enable non-MQTT devices like Modbus to be onboarded to MQTT systems without losing device interaction semantics, by publishing TD-described data over MQTT.

• Major companies like Microsoft, PTC, and Siemens are adopting WoT concepts like TDs for device integration and interoperability across protocols.

• Open-source resources like the Eclipse ThingWeb project provide tools, libraries, and TD directories to work with WoT standards.

Transcript

Introduction

Scott Baldwin: 00:00:05 Welcome everybody. Thanks for joining.

Scott Baldwin: 00:00:06 I'm going to introduce Ege Korkan. He's an R&D scientist at Siemens AG and based in Munich, Germany, and also a member of our HiveMQ Community. He works on the Web of Things topics and is active in its standardization in the working group and also co-chairs the community group at the W3C. He contributes to the open source community, mainly at the Eclipse Foundation via the Thingweb project, and also has written extensively on IOT, open standards, and the Web of Things.

Ege Korkan: 00:00:34 Thank you. And welcome everyone from my side. So today's talk as Scott has mentioned about context for MQTT. And I will share how the Web of Things can help with this.

Ege Korkan: 00:00:46 So very shortly about me. I've been doing R&D at Siemens for the last two years. And I did a PhD beforehand, and you will see me in multiple places, but I basically support everything that is open source and community driven and it's a perfect place here for this as well. You will see me in W3C or in the Eclipse IoT Working Group and the web project. And also, lately with the asset analyzation shell topics that you might see popping around. You can find me in multiple places, but maybe most importantly in the HiveMQ Slack. You can just join me after the call or anytime and ask any follow-up questions.

Building Up an MQTT Architecture

Ege Korkan: 00:01:22 I will start with MQTT and what we will do is build a very simple, sort of simple MQTT architecture, but, and do it step by step.

Ege Korkan: 00:01:30 So what you are probably already aware of with MQTT we have a broker somewhere and we can connect multiple clients to it, and we can establish different kinds of communication patterns, so a 3.1 publisher, subscriber or multiple, but we can really use it as flexibly as we want. And as also mentioned in other talks, this flexibility is maybe one of the most important assets of MQTT, where we can really adjust to our needs and those needs — the concept of adjusting to the needs — is very important for this.

Ege Korkan: 00:02:02 So I'll start with a very simple temperature sensor, let's say it's connected to a broker and publish it somewhere to a certain topic. And of course we should have a subscriber so then can basically plot or show the temperature in a gauge, to show the current value.

Ege Korkan: 00:02:18 But what if it gets a bit more interesting? What if we also want to include the unit into the payloads we're putting, because maybe we have different subscribers we are serving. If it's in the US, then maybe those there will want to adjust based on the units so that it shows, like, not 24, which would be minus degrees and shows the correct one for the region there. And then, same for Europe so that's basically adjusted all the time based on the units.

Ege Korkan: 00:02:42 But ideally an MQTT broker has multiple devices connected to it, so it's not just for a simple temperature sensor. So what if we start having more devices, like now a presence detector. And even though they are publishing different topics, you still decide to include the device type into the payloads so that you can have different subscribers, like one that shows temperature again, and the other one shows an intruder alert.

Ege Korkan: 00:03:06 But let's take it a bit further. So now let's say that I want to adapt my dashboard accordingly. And for this now I'm supplying also a description. So the description will be then used by the dashboard. So it slaps it under the gauge and shows the description that is sent by the sensor.

Ege Korkan: 00:03:23 Let's go even a bit further and also start putting the measurement date. So not when it is re published, but like when it was measured last time. So that we have different subscribers now that can use it differently. So one can just again plot it, but the other one can also display the evolution of the temperature over time. And what is happening here is we are adding more and more data.

Ege Korkan: 00:03:44 And sadly the title space of the template provided by Siemens is too short. So now I will go and change the template so that we can add more and more data to our payloads. But maybe we should better not do this and we should try to understand what's really happening here.

Ege Korkan: 00:03:59 And maybe you are thinking that it's like a theoretical example or that it doesn't happen in real life. But actually, if you ever use Philips Hue or Signify products at your home, it has an API, so HTTP API in this case, and you will see that there is a lot of data being exchanged. So if you just want to get some light information or just the state of the light, you will get a bunch of data. So like you're seeing here, the software version is received each time you want to know whether the device is turned on or off. So if you have a Philips Hue app, or even if you use an open source project, you will always get this information even to just know that it's on or not.

[00:04:39] So what is really happening here and why does this happen? The simple thing that you're observing is that the payload is getting bigger to accommodate everyone's needs. And actually these are different needs.

Ege Korkan: 00:04:50 So not necessarily how everybody wants to do the same thing. Because we have multiple and different subscribers and not necessarily all of them are doing the exact same application with the data. So in the end we have more data, but at the same time we have more metadata and the data and the metadata is mixing up and is the main cause of this payload getting bigger and bigger.

Ege Korkan: 00:05:11 But what is metadata, and why did I start the presentation with the word "context" and what does it really mean?

Ege Korkan: 00:05:17 So for this, I will try to look into the state data we were sending and look at what is changing all the time and what is not. So things that are static are, as you probably understand — the device type. So the device cannot become a humidity sensor the next day. And the description of the measurement is probably also not going to change, it's still measuring temperature. And some things might change, so maybe the units can change, but something easy to change or the software version can change. These are not changing that much, but can still, and there are things that are definitely changing all the time. So that there's sensor measurements, measurement time, and so on. These will always change.

Metadata vs Data

Ege Korkan: 00:05:53 And for this, that's where I would like to categorize based on this and put the first two into what we would call the metadata and the second into data. And what I would like to advocate for today is to really think of when you're building such an architecture to decouple, how you manage the two types of information and to not try to, smash everything together into one solution.

Schema Languages

Ege Korkan: 00:06:15 And if we think of this context, we can start using some schema languages. Why? So actually, if you think of it, even adding all of this data was still not enough. So there are still open questions. How do you know the minimum maximum of the temperature is 24, a low temperature or not? And what device types are possible. What does device type imply? Maybe I have a knowledge base somewhere and does it relate to this? Does it link to this? What is the date format? So we were using the ISO dates format, but it doesn't have to be like there are, I don't know, Unix timestamps and so on. It could be anything. This whole thing with the units, were we really constrained to using Celsius with the C or could it be like anything else?

Ege Korkan: 00:06:56 So for these kinds of questions we can use schema languages, JSON schema is a very prominent one. It's also an open standard. And if we start thinking of this, we can have a JSON schema like this and for this simple case, it's a rather simple schema.

Ege Korkan: 00:07:09 So we can start putting like the min max values of the temperature. And we can put the units of course. Important detail that the min max will change based on the unit, but let's not get into it. We can say that there is a device, it's a string. And then go on to say that, okay, the stage we were talking about is this kind of format, which is by the way, the isolate format based on the schema. And actually, we can think of it differently and start restructuring this so that, since we know that this is always the oven temperature, we can put, for example, a link to say that this is oven temperature. You don't need to redefine the device types and so on, but you can link to it and you can start putting descriptions in here. So not necessarily into the data. And if you do this, you will see that your data gets smaller. So instead of putting more and more keys and so on, it becomes more streamlined. But you are not losing any information.

Ege Korkan: 00:07:59 Now we can go a bit further. So what if you want to have more information about the device? So what if it's publishing to multiple topics? So like a list of all topics and maybe it publishes some with retained flag. And I don't know the different quality of service levels, maybe subscribes to some of them. Maybe you want to calibrate this temperature sensor so you can send it a command to start a calibration sequence, like the device type. So like we're knowing more about this device, it would be interesting. And if you're really thinking of multiple regions, then you will start having multiple languages of descriptions and so on. So it will get probably a bit messy. But in the end, the question is, can I simply get more information about the device without putting everything into my payload and hoping that everybody gets that data at a certain point of time.

Getting Device Information

Ege Korkan: 00:08:45 And we would like to say that yes and thanks to the Web of Things and the MQTT binding there, we can really start to have more information about the device while not increasing the payload size and so on. And let's get into it. So no more teasing, but what is Web of Things now we can see with some concrete examples.

Overview of The Web of Things (WoT)

Ege Korkan: 00:09:04 So Web of Things is basically a family of W3C standards. So W3C is the World Wide Web Consortium. So where most of the web standards are standardized. So HTML, CSS, lately things about, yeah, verifiable credentials and this kind of topics are all happening there. And as with all W3C standards, it's royalty free and open. So you don't, yeah, we will never know if you're using it and it's for you to just go on and use. We really pay attention to becoming developer friendly. Everything is kept to a simplicity goal, and it only gets complex if the application is more complex. We are having market adoption. So multiple companies are using it, along with open source projects that are, like native Web of Things projects. And in the end, in its core, it’s about having reusable API descriptions for everything. And with everything, we really mean any kind of device that is out there that is connected to the internet. As I said, there is an adoption happening with multiple companies having products or are using it in their products to simplify some aspects and these are also getting recorded.

Ege Korkan: 00:10:14 So in the Web of Things community group, we can have a look at the YouTube channel to see different companies using it or different open source projects. So some of them are not products like this last one we had with the microscopes. It's a global open source project that is using Web of Things, and we can just do the same. And if you want, we can also have a look at how people are using it.

Bridging Network Protocols to Applications

Ege Korkan: 00:10:37 And what the Web of Things — what we are doing is very important since it has the web in itself. It doesn't really mean that we are really talking about the web browser. It's just having the same ideology that like the web unified the internet, so we can really unify the IoT with the Web of Things. And what we really want to do is bridge the network protocols to the applications while not changing those network protocols. And what we have in this case is the bindings. So like how we really bind to these different protocols and then the interaction affordances, which are like the capabilities of the device. And on top of it, we can then add semantic information. So it really puts more information about the device, like all the similar readable information or use of well-established standards. And this part in the middle is called a Thing Description, which we'll get into in a bit, and is basically a part of the Narrow Waist Model of the Web of Things where all the protocols that we can see like MQTT, HTTP, OPC UA, Modbus, or anything can be described without changing the protocol. Then you can really focus on the application logic so that you can build these applications that talk with these devices.

Ege Korkan: 00:11:42 And for this, the core specification is the Thing Description, and we have some focus areas here. So the first part is the effect in the real world. So we really want to focus on how this device affects or how the real world affects the device. And for this, we have properties, actions, and events. And we have the concrete protocols inside them. So with this forms object. And as mentioned, we can really bring the domain knowledge of your company or any kind of domain into the Thing Descriptions so that you can really enrich them with domain knowledge you have. And it's not just some boxes around, it can be re serialized in the JSON LD in a rather human readable format actually so that, once you have it in a file format, you can really think of discovery use cases or start using them by your clients to build applications.

Ege Korkan: 00:12:29 Like I mentioned, it's all open standard, so you can have a look yourself. It's public in the W3C. You will find the W3C recommendation, which is the keyword for the stable standards in the W3C. I will get a little bit deeper into it so that we can really start doing a demo in a bit.

Introducing Thing Description (TD)

Ege Korkan: 00:12:46 What we see here is the first sort of level of a Thing Description (TD), and I categorize it into different information we have. So one part is the thing metadata. So that's where you will find all the information about, human readable stuff, or if you have ideas, or if you're managing these Thing Descriptions, then the ideas and so on become important. We have the semantic annotations, so these are where you can bring this domain knowledge using established ontologies. And very importantly, we have the security metadata, so not the credentials themselves, but what kind of credentials you need. Then we start getting into the important things with the interaction affordances, so the fact that there is a temperature property that I can read or that I can start this sprinkler device. Or that it can notify that the soil is too dry, when I subscribe to an event, and of course we can also then add more stuff. Like we can link to our documentation. We can link to our, I don't know, UI or any kind of support website and so on and so forth.

Ege Korkan: 00:13:37 Going into the interaction affordances in this case, we have properties, actions, events, and what you see here, temperature, starts sprinkler, and a too dry event. And in this case, we can also add more metadata if you want. So for, for human readability purposes, and we have just a schema like we've just shown, so you can really model the type of data you are expecting from a device, or you can send to the device and then you can go to the concrete protocol information.

Ege Korkan: 00:14:05 And that's where we get into the MQTT in the Web of Things. So here I have an example and just to show that we really have real protocol information. We have the URI of endpoint. So it would be different protocols like you see with HTTP and MQTT on the bottom. And then we have the intended Web of Things operation. So what you want to do with this resource is important. And then what gets more interesting is that you can really put protocol specific vocabularies in here. So these come from the standards themselves. So we are not inventing these words ourselves. So we use the standards or if the standards provide already these ontologies, we can just simply reuse them. So that means that if you are already familiar with that protocol, you won't feel alone, so to say.

Ege Korkan: 00:14:52 So I did all of this talking and tried to explain the Web of Things, but did this first example with a lot of data in this device, did it get any better? I think that it did, and I will show it.

Ege Korkan: 00:15:03 When we left the temperature sensor, it was sending all this kind of data to the broker. And what we can change is that like the description and unit, they can all become part of TD. The device type will be understood by the TD and can have more context about it. The data that we're sending, the value and the timestamp and so on, it will stay the same. The topic will stay the same but we can actually even do more. Now I will switch to the TD itself. So I actually retry to put more information to give as much information as possible to the device without complicating the data itself. I put the screenshot, but it's just for further reference in case people find the slide somewhere.

Ege Korkan: 00:15:40 So now I will switch so I will show two things. So this is a pure JSON editor that has validation capabilities. And on the other side, we have a rendered version of it. So it's a suggestion, you can render it and have an easier way working around so you can really see the difference affordances we have. I will stay here since I really want to show the details of it so that we can, yeah, understand everything that is really happening. So actually I have also added multiple languages, so you can see that there is English and German included for all of this human readable information. You can also externalize this information if you want. I have added further information. So if I want to explain the software version of the device that is running this I can add this and in this case, I do not have any security since I want to really put it available there for everybody to try. So I have basically two properties, so temperature and the, I also have a simple example with a bit less information so there I didn't put the, all the timestamp and so on kind of stuff. So it's just basically a number between these two values. And what we see here is the full example that you will be able to interact. And I am also using units that are well established. So the units of measure is a well known ontology for, yeah, basically a catalog of all the possible units. And what we're seeing here, that is important part, which we'll get to in a bit, this is where all of this data is living. I basically connected to the HiveMQ free public broker, this one here that I think people here generally know, and I have picked myself a topic, so there we can be flexible, but for now I pick something and of course you can just subscribe here to get the data.

Going Live with MQTT

Ege Korkan: 00:17:17 So we can go live with it, and if you have a simple MQTT clients handy you can simply start using it. I will start the device in a second. As mentioned, it's connected already to HiveMQ and there are also other kinds of things you can try in the Eclipse thing web project, and also what's Web of Things specific libraries, but actually don't need to. So if you just want to interact with this thing, you can just go ahead.

Ege Korkan: 00:17:41 I will just start it. What you will see now is that I am basically emitting the temperature values. I will make it a bit bigger for everyone. So I am now emitting, of course, in this case, random values as I don't have the hardware with me. And if we go now to a very simple application, we can start seeing the values. And you don't need to have any level of things knowledge. All you need to do is once you have this Thing Description, you know what broker you need to connect to, what topic you need to connect to, and you can just go ahead so you can also use the web socket clients of HiveMQ. So as you see here, it's connected and it's getting the values correctly.

Ege Korkan: 00:18:21 And I also built a very simple Node-RED application. As you see here, there is nothing Web of Things specific. It's just connecting to the broker I specified and put the topic. And I know that it's this topic, since I have the Thing Description at hand. This function is nothing crazy. I'm just basically getting the value instead of the whole thing. And then I'm putting into a chart with the Node-RED dashboard so that basically I can see something like this getting plotted. And as you see, I had to change nothing. Maybe if you try it, let me know if it works or not. I think it works. And of course, the dashboard and so on is living in my computer, but the data is publicly available. In the Q&A session, if you have any questions, if this doesn't work, you can let me know. But basically, if anybody wants to run directly, it will be just this basic I can paste it in the chat if somebody wants to try.

Demo Takeaways

Ege Korkan: 00:19:11 All right. So first of all, you don't have to change the protocols, topic structure, payload structure, or whatever to use the Web of Things. So you can just, as shown, use an off-the-shelf MQTT library.

Ege Korkan: 00:19:19 And if you want to remove the human in the loop, then you of course need to implement the TD parser so that they go through the JSON and the topic themselves, it's just a simple code you just need to go through the parser JSON. So there's nothing crazy to parse. Of course you can basically use any existing MQTT library there is nothing crazy. And the code I have shown, it's also using the MQTT JS library, but if you program with another language, you can just take something you like. Of course, the most important thing maybe is that when we move the metadata to the Thing Description, it simplifies the data flow so the amount of data being exchanged and what we need to understand. And it unlocks more knowledge about the devices then what you would hope to pack in the data that you're pushing around.

Ege Korkan: 00:20:08 So if you like this, you can join the working group to drive the standardization as well. It's open for people to improve even the MQTT and binding. So we have some still small things to improve, like these new request response mechanisms in MQTT5 that we do not take into account yet. So if you have some existing MQTT use cases that you think are not possible in the Web of Things. Just approach us and we can work to put it into the standards.

Going Further with the Web of Things

Ege Korkan: 00:20:36 And with the last part, I want to go to this part where we can read things a bit further and just MQTT. Actually what else can we do with the Web of Things? And in the event description, we put this part about how we can onboard non-MQTT devices into MQTT systems without losing any meaning of the interaction of the device.

Ege Korkan: 00:20:59 So what does it really mean? And what we see is that given that the protocol is kept in this forms level, so that we have a temperature. But unless you go into the forms, you don't know that it's MQTT or not. So you can actually just describe the real device, let's say it's a Modbus device, and then once you consume it with your Edge platform or any kind of platform, you can re-expose it with MQTT. So basically you do a Modbus request to read register, and then you publish the value to MQTT. And you keep the same application logic and the TDs can be provided by device manufacturers, or they can be written by or generated by the community. So you're not locked into the or you're not waiting for the manufacturers to do it. And from Siemens, there will be some devices in the future coming so when we think of it, this becomes an onboarding topic. And this is also happening in multiple places with different solutions. Actually, there's one from HiveMQ, the HiveMQ Edge. It uses things that are like Thing Descriptions, like what we see here, but the Modbus configuration. In the PTCs ThingWorx, there are also Thing shapes that are, yeah, doing more of the same thing. I just didn't manage to find a public screenshot to build the documentation of this. And Azure for Microsoft are similar concepts happening with the digital twin description, definition language, the DTDL, and also in the OPC UA world, the Web of Things is now chosen as the way to onboard non OPC UA devices into OPC UA. So basically you can have a Modbus Thing Description. And it's onboarded to an OPC UA server through the protocol stack.

Onboarding via WoT

Ege Korkan: 00:22:28 And yeah, so there should be some publications of this group also in the very near future. If you want to learn more, there are a bunch of stuff available publicly. There's the official Web of Things webpage. So w3c.org/wot. You can try many of the open source projects. There's a developers page available here with open source solutions, there's documentation, there are videos, there's a lot of stuff. You can also join the community group to show or see how people are using it. There are many ways to learn also social media and so on. We are active.

Ege Korkan: 00:22:58 So thank you for listening, and I'm happy to take questions.

Q&A

Scott Baldwin: 00:23:01 Awesome. That's great. Thanks. I appreciate it. I guess the first question that came in here is from John and that's in the context of MQTT and specs like Sparkplug B. Are you able to publish the non changing parts like context with a birth certificate so that it's a one-time data send? Or is there a different approach that you need to take to undertaking that?

Ege Korkan: 00:23:25 Yeah, so I follow the Sparkplug standardization a bit and in the latest version, the restriction on this birth certificate is removed. So you can actually now use a Thing Description to [inaudible] that you publish doing the birth message and it is then retained in the broker or you can even theoretically just publish a link to the description then you can do it a bit out of band. And so in that case, my answer is yes, definitely.

Scott Baldwin: 00:23:53 Okay. Excellent. Thank you. I know there was a question here earlier from Andreas, maybe a little bit more technical in nature, but it was why does the time have an additional time string?

Ege Korkan: 00:24:05 I will go to get into it because with MQTT, the way you format the payload is of course flexible and you can just use a plain text if you want. The reason this is happening is I use the JSON stringify, and it is putting this additional — actually it shouldn't have been even needed. But it's just due to the just notification of the payload. So probably for your demo, this is just the nature of it, but normally you probably wouldn't pass that type of value over as part of a string of this type. I can even try to remove it and let's see what happens. Okay. So it just works. Okay. So then there isn't this additional one. I think it shouldn't affect my demo either.

Scott Baldwin: 00:24:45 Funny. Like, we were geeking out on the code here a little bit.

Scott Baldwin: 00:24:48 What are your feelings about the adoption of Web of Things versus maybe others?

Ege Korkan: 00:24:55 Yeah. I don't think there is a direct competitor, so to say, above things that is an open standard and so on. So there are the other ones. So there are some things that can be leveraged. So actually this cannot become a Thing Description because you're actually giving the destination public and so on, so you cannot just replace this whole thing with the Thing Description, but some of this could be replaced, like the word Modbus IP addresses like IPV4 and this kind of things, they can be replaced. And if the manufacturer is providing this, then your job becomes easier. And regarding DTDL, there are some works to converge the two. So there might be some things that we explain later on. And for the other two, so the PTC, I don't have a contact, so I don't know how it works, but there are actually some products like this onboarding products that already use Web of Things.

Ege Korkan: 00:25:44 So if you go to this out here, IOT, which is another IOT platform, the devices are onboarded with Thing Descriptions. So it's, it really depends on if people are adopted and see value in this. But we are already seeing it happening because it decouples it from a certain tool, and you can just have a single source of truth for this kind of onboarding information.

Scott Baldwin: 00:26:06 Okay, great. And I know we have lots of different shorthand in this presentation and talk and stuff like that. There's a question here regarding TD. You mentioned TD or TDs a few times. I'm assuming those are Thing Descriptions, but is that what you meant by when you mentioned a manufacturer as a TD or?

Ege Korkan: 00:26:24 Yes. The TD is a Thing Description, and it's basically this JSON file.

Ege Korkan: 00:26:30 I also saw another question regarding ontology of units. So there are what is known as ontologies that explain basically like a catalog of information, so linkable information. So basically if you ever want to talk about software information, you can see the link here, by the way, this is what is used by Google search. So if you ever search something, and there's this little card that pops up on the right hand side, they are using this kind of information.

Ege Korkan: 00:26:54 So if you go to like schemas, you find a lot of information about different types of stuff. Basically they are modeling the world, so to say, and this is the part of the units. So you don't need to define these like words, like just the word itself from scratch and hope that people really understand because even something like temperature could be different. There's color temperature, there are different types of color temperature. And it's also here, you have a catalog of different units and even things I have never even seen before. So we can just reuse these instead of inventing it and you can then live through this. So that is the important part.

Scott Baldwin: 00:27:33 Yeah. I imagine there's some huge advantages to standardizing some of this, both in terms of speed, like you said, you don't have to spend the time coming up with the ontology, but you also have some more consistency between devices if they're talking that way or working that way.

Ege Korkan: 00:27:46 There was another part of the question, can everyone publish team descriptions here? So here, yeah, no, you wouldn't publish TDs. These are more, I would say abstract concepts. So it depends a bit on the ontology, but there are public team description directories, so I didn't get into it in this presentation, but you can actually go to, oops, and then to the list of tools. So in here, there are different TD directories being listed. So you can actually pick one of them and use it in your application. So they differ a bit. So like the program language is different or the database behind is different, but these are all things you can use for storing TDs and you can self-host it.

Ege Korkan: 00:28:30 And some of them like the Zion here has a public TD directory for you to test stuff.

Scott Baldwin: 00:28:36 That's great. Wealth of resources that the W3C has built out. Appreciate all your effort on this, it's really great.

Closing Words

Scott Baldwin: 00:28:43 All right. With that, I think we don't have any further questions. I'm just going to share a screen here quickly and we'll wrap things up. Again, thank you everybody for attending today. There will be a post event survey. Just ask you to take a moment to share your thoughts on the event afterwards. We really do appreciate that feedback and like to share that with our speakers

Scott Baldwin: 00:29:01 If you want to continue the conversation, Ege will be available within our community. You can reach out either through DM or obviously through one of the threads that we have open on the community side.

Scott Baldwin: 00:29:11 And if you do want to speak or have something you want to share about your practice or the work that you're doing feel free to let us know. We'd be happy to reach out through our HiveMQ community to have you involved and sharing some information on that end.

Scott Baldwin: 00:29:24 With that, thank you very much, everybody. Again, thank you very much for attending and for sharing your input here and leaning into this conversation and thank you again and have a wonderful day.

Ege Korkan: 00:29:35 Thank you all for attending and feel free to reach out.

Scott Baldwin: 00:29:38 Sounds great. Thank you.