 Okay. Thank you very much for coming. This is just a presentation about using XMPPE to connect Internet of Things. Just kind of a word about TIGASAY, who we are. We began as an open source XMPPE server in 2004 from One Person Project. We're now six people. Our flagship product is the TIGASAY XMPPE server. It is open source and platform independent. It runs off of Java. And we specialized in custom application and modification of XMPPE servers for specific applications. And we just released version 7.1 just a couple of days ago. So we're kind of fresh off of that and onto some new stuff. So what is XMPPE? It stands for Extensible Messaging and Presence Protocol. Most of that is pretty self-explanatory. So I'll kind of skip the next couple of ones here to kind of go on to the next thing. XMPPE takes place, of course, in a single stream of data. So it goes back and forth until you no longer need to communicate with the server and the stream ends. As you can see here, it is all based in an XML markup. So everything has its own child elements from there. Communication is broken into three different types of standards. There are short contained XML messages sent through the server to either a component or another user. And they come in three types, presence, IQ, and message. And the addressing standard is known as the Jabber ID or JID. And can either be broken up into a bare JID, kind of like an email here, or a full JID which has a resource. The resource can be used, say, if you have a tablet, a mobile phone, and a desktop computer. They can all have the same log on, but they all have different resources, so you can address them specifically. Just a little bit more. The basic structure of a stanza will have a type, usually a from or a to, and related child elements. So moving on to presence types, you have, excuse me, stanza types, you have presence. This can indicate a user status, whether they're away, they're away, unavailable, or available for chat. They can be used for triggers for events, so if somebody signs off, hey, some other stuff happens inside the server as far as logic is concerned. They can be sent by servers, clients, or components. There are five different show tags, and they can all be extended using the status element. And that's kind of a text string that'll explain what's going on. I'll skip priority and see elements. That's just kind of a basic presence stanza that you can see inside an XMPP server. Messages are kind of the bulk of what most chat servers will use, and they're designed to carry person to person text. They can be enriched if needed, and we have five different message types. Chat, group chat, headline, and normal, I'm sorry, and finally error. Again, I'm kind of moving through this kind of quickly to get to the other real meat of this presentation. They can have some specific elements, but body is really the main one we're concerned about. That's kind of where the meat of messages will work. And we can use things like, for example, we can use HTML to enhance those messages, make them look sort of fancy. Info query is the last type of message stanza. This is kind of how you can get and receive information to the server. It opens up a method for a response and request mechanism, and we have four types of there as well. Set, get, result, and error, which I'm sure you can discern the meanings thereof. This is sort of a pair of examples using disco info protocol. How can I get information about, for example, information for multi-user chat? And this returns some information about which ones are available on that room. And then components are items of code that extend these server operations. They will typically have a jet assigned. Three typical ones you'll see is PubSub, Jingle, or Muck on a server. And PubSub is kind of an important one as we'll see in a moment. And it's designed to provide a polling service. You can find information there. Things will publish information. You can receive information and receive pushes from those spots. They're organized into nodes. Nodes will be stored relevant information. So in a moment you'll see kind of how useful nodes can be in this scope. And users can subscribe. They'll receive notifications about new information that's pushed there. And then you can also look up older information if you want to have, say, the last several publishes to that node. You can get historical information from a PubSub node. Kind of moving on to our second topic, Internet of Things. Is it really secure? Most consumer devices will have a login page like this and that's it. And probably about 90% of the ones out there you could log into with admin-admin. Oh, wow, I have access to this device. Not exactly the most secure platform out there. And this is kind of what things look like right now. And this is a bit of an issue because I'm sure many of you are aware of the DOIN attack that happened back in October. That's kind of a heat map of what we're looking for, which was primarily done by malicious code on Internet of Things devices that were insecure. Small bits of codes were thrown in there. And this is the largest denial of service attack that we've had up to date. These will probably be more frequent if nothing is done to sort of secure that end of things. To that end, why would we want to use XMPP as a solution? One big one is security. The XMPP server can use limit to network traffic only. So, for example, if you want to just set up a home security system and only have people inside the house control it, that's easily done. We can filter traffic using the XMPP server logic. And we have some device isolation that allows for devices not to be touched by anybody outside the network or indirectly affected by people. And again, authentication can be more than just a simple password using some standard features that XMPP servers come with. There is a bit of an ease of use as well. XMPP servers already designed to handle that two-way communication that you would expect. So you wouldn't have to worry about, okay, how do I get this device to talk to a phone or another device or a hub? There can be scripts for automatic setup. If you turn on another device inside your network, the hub or the XMPP server says, oh, that's there or he sets it up for use. User can change the name of these pub sub nodes. We'll see in a minute. So users can configure how these work. And again, easy network configuration. XMPP already does NAT translation. So you really don't have to worry about accessing it from outside of the network and creating certain holes if you need. And we can have out of the box secure functionality with an XMPP server. Cost is kind of interesting too as well in terms of if you're developing some hardware. It's a well established platform. We've been around for a while as XMPP. It is an open source protocol and you can customize to whatever you need. But you don't have to basically spend money to use XMPP is that particular thing. And again, our solution and other solutions are platform independence. You don't have to use one specific device or one specific operating environment. So in this case, what we've produced is sort of a particular use case, for example, and I Internet of Things thermostat. Really all we're looking for is, okay, we want to get what the temperature is. In this case, it would publish to the PubSub component on the XMPP server. And that alone isolates that device from anybody who wants to put malicious code on there. Any sort of information that's passed to the thermostat has to go through the server and the PubSub component, which means that has to be formatted correctly. Otherwise it's going to get rejected almost immediately. And there is another step to go through in terms of if you want to connect to the actual thermostat. So how can this be done? As again, we saw on the diagram, the PubSub node acts as an intermediary. So we can have and what we've designed is that the devices is a root node. And then underneath that root node, you have a device name for each device that may be on your network. And then you have a state and a config node. State, obviously, what's the current temperature and config if you want to send some configuration to it. That will only be allowed through an admin user, but typically somebody who just wants to get in isn't an authorized admin, can only receive the state information from the node. And information is published to their associated node. So you can have multiple thermometers. Each node can be renamed on the fly. So you can have it upstairs downstairs or living room, whatever it might be just sticking on that. And the device itself is responsible for running the application and obtaining configuration from the PubSub node. So it kind of separates the two a little bit. Here's kind of an example that we're using. We're using 323, which is IoT sensor data that is contained within a time stamp. In this case, we're just showing that in this case, this is a light sensor and we just have a value of 37 lumens. And users can connect to that node and just attain current temperature, lumen, whatever they might need. So the configuration nodes are reserved to push information and configuration changes, and they can only allow local traffic or admins, however you might want to set that up, to change your settings depending on how the hub may be configured. And again, they can only be limited to data forms that we're looking for. So we can't put malicious code in there. It's only going to look for properly formatted stanzas to pass through. These are some X and PP stanzas of how to connect and what we're going to see as far as the transmission, just in raw stanza. So in this case, we're just asking for the initial state from the device. And MaxItems1 is just showing the most recent published one. The sensor will then respond with its current read state. In this case, we're getting a 23.25 degrees Celsius temperature readout again in that time stamp form. And that's pretty easy to scrape in terms of where to pull that information and what you're expecting. It's going to show in that format. So it'll be nice and simple there. When a sensor has new data, it wants to publish to the PubSub node, it'll send another IQ stanza to the PubSub node specifically. It will report a new temperature, and that will be given an item value by the server itself. So we can, excuse me, each new publish will have its own item so you can look up historical value later if you want to do that. In this case, if we want to publish a configuration change, the device will publish its initial settings on startup to the configuration node. This is much longer, but this is just a couple of values. The server will respond with an item set, and if you want to change those settings, obviously you would have to be in the same form and all the values that we're expecting. We've also created a user interface which completely obscures the XMPP portion. And again, we'll just take that information, put it in user-reasonable data, which is kind of handy if you want to have something as a complete solution. As far as being able to expand this sort of thing, new devices and values are easily added. We don't have to, you don't have to use any XMPP as far as new drivers and devices. It can all be done in Java. The framework is similar to previous TigerStay frameworks. If you ever worked with one, it'll be pretty easy to pick up and go with. And device types and sensor data are independent, so you can have multiple types with different sensor data if you want. And again, intense knowledge of XMPP is not necessary as coded in Java. Oh, I just went one by one. This is sort of a quick example of our little system working here, running a, just a light setting example. Just have a camera on the side there, just kind of turning lights on and off, so to speak. But we do have a functional example running. And here we're changing the name of the PubSub node from lights dimmer to, I think, just dimmer. And this is done quickly on the fly and the server just adjusts automatically, which makes that nice and customizable. Again, here we can see quite a few settings that are available that can be changed using publishing new configuration settings to the config PubSub node. And again, just to show how quick it is, XMPP is rather instant in terms of changing these settings, so it is something that can work. And the nice part is we do have several zips available on the XMPP website, but we've used basically one that's pre-existing and one that already exists. So we, the option to, I think, what has happened here? I think it broke. Okay, thank you. The computer has decided not to display anymore, so we may have to just look at the smaller preview for the moment. So we've had a couple of options as well as terms of solution. PubSub is one instance that we can fix this Internet of Things solution. Another one is being able to send a direct message through an XMPP server to a device. And in fact, we have a sort of a live demonstration here. Unfortunately, people in the back can't see, but we do have a little robot down here that's receiving XMPP commands and returning sensor data to the XMPP server to say, hey, I've stopped, I've turned, I've gone left and right. And this bot is actually just receiving messages, message stances directly to the device. And all it's doing is carrying out those commands as asked. Unfortunately, I don't have... I think your presentation's in the background. At the bottom there's a bar. Oh, is it? Oh, thank you very much. Okay. So in this case, we will require some log-ons to address those things directly. But the nice part is we can do some reduced overhead. And again, the device still requires a properly formatted XML stanza, so we can't really send anything malicious or anything that it's not expecting. In this case, we're just sending stanzas like these. And if, for example, to move forward, the bot will respond, hey, I've moved forward and it will use chat states to basically say, I'm executing command. Once it's done, the chat state will basically go to idle and then it will send back a message saying that it is done. Our framework is open source. And as of this morning, we've opened it up to anybody who wants to jump in and kind of mess with the code. It's available on projects.tigase.org. And they're separated. We have an IoT home, which we saw earlier in the demo. This turtle bot is there. The only requirements we have right now is a device bridge, which we've used Raspberry Pi 3s. And Tigase server 720 are newer operating on the same network. That's all I have for now. Any questions about this implementation or source code thereof? We have three minutes. A couple of questions. Questions? Just a curiosity actually. Isn't XML in general a bit verbose, for small devices? Or did you add some improvements and adjustments to make this, let's say, verbosity in the terms of messages that are being exchanged less problematic? We haven't really worked on the verbosity of XML very much. But what we've done is essentially we wanted to make a representational case. So essentially this works. Here's how it could be done is more what we're going towards. In terms of truncating any of that, we haven't done any work there, but I'm sure it could be done. Thank you. Yes, sir? How do you handle authentication? In this case, for authentication, for Pub-Sub, we can use anonymous users if we just want to use, if we just want to collect data. For the message bot, well, yeah. It can be also done in such a way that each device will have embedded its own private JIT and its own private password. So every device will have separate passwords, separate logging, let's say, and it will create a specific account on our server. And our server can allow it or not. It's up to us or user on the end to decide if you want to decide if this device should be allowed to attach to the server or not. When you say our server, do you mean tiger say server or the users? Generally, it would be any XMPP server, right? Yes, sir? MQTT seems to be popular also on IoT devices. So what's the disadvantage that they're against the solution? MQTT is fine in local networks, right? However, when you would like to expose or access this network from the internet, then you will need to go through navs, issues, et cetera. With XMPP, you can connect or explore, allow connection to XMPP server from outside networks. Easier, and it's already done, so this is the advantage of this solution. This small talk to us is connected to our company server. So it works as XMPP client and I have XMPP client on my laptop. That's all. That's all I have to tell you guys. Okay. Thank you. Thanks, man.