 Well, yeah. Hello. Welcome, everybody, to the talk. Real-time chat on the web. I'm J.C. The Dutch people will be able to pronounce my name easy. It's Jan Karel. So this is about real-time chat using XPP and JavaScript library called ConverseJS. I'm not going to really go much into what XPP is. I don't have a lot of time and quite a few slides to show, but just as a quick overview, it stands for the Extensible Message and Presence Protocol, which kind of explains quite a lot of what it's about. It was originally known as Jabber and used for instant messaging, also for signaling. For example, video conferencing or file sharing or also lately using for Internet of Things applications for interoperability between different devices or to be able to communicate with your IoT devices via chat conversations. I gave a talk about XPP about three years ago at a PON conference, a kind of introductory talk where I'll go much more in detail about it. So there's a link. Oh, the slides are live over there. ConverseJS.org, Fortress Slides, FOSSTM27 with a dash, index HTML. Are they open for editing? No, not yet. Not currently. So, yeah. One of the first things you'll recognize when you're trying to integrate XPP chat into a website is that XPP is a fundamentally different protocol and it expects you to have a TCP socket connection to a port that's different than your web server ports and the browser's sandboxing doesn't allow for these TCP connections and doesn't have any APIs for it. Additionally, the two protocols are conceptually different. So for example, HTTP is stateless. It's request-response-based, so you can never get anything from a HTTP server that you didn't first send a request for. And it's also stateless because any request you send is fundamentally independent from any previous request you send, at least on the protocol level. And also, generally, the connections are short-lived. So, XPP is stateful. It's interactive and bi-directional, which, what I mean by that is you can at any single time receive data from an XPP server unannounced and without having asked for it. And therefore also requires, generally, is dependent on a more long-running connection. So when we think about how to integrate XPP into a web app, I'm going to split it up into two areas or domains, what I call front-end integration and back-end integration. Here, I have just a little graph or graphic where I show your web application, web browser and XPP server. Generally, you will have HTTP traffic between the web browser and your web application or maybe web socket. Now we're bringing an XPP server into the mix and it's possible to have direct communication from your web browser to the XPP server. I'll explain how that happens, bridging the problems I mentioned just before of the protocols being different conceptually. But you could also have communication directly between the web application which is running on a server somewhere and an XPP server and there might be reasons why you want to do that. So, starting with the front-end integration, to bridge this problem of the protocols being different, you basically have two things you can do. You can, so to speak, tunnel XPP through HTTP or you can do XPP over web socket. And so the way you do the XPP over HTTP is through a technique called Bosch. It stands for bidirectional streams over synchronous HTTP. It's not XPP specific, but it comes from the XPP community. It's already since 2004, so it's really an established way of doing things. You do get this bidirectionality. In other words, you are able to receive data from the server, in this case a web server or Bosch Connection Manager. And the way you do this is through long polling. And the way long polling works is generally a web server, when it receives a request, it will fulfill the request and then quickly return a response. With long polling, what the web server does is it holds onto the request and doesn't immediately return a response. And it waits until asynchronously it receives data that is worthwhile, that makes sense to return. For example, in the context of instant messaging, it would hold onto the request and wait until it has any instant messaging data to return, and then it will return a response to the web client. And immediately the web client will make another request. And if you have a timeout, so maybe 30, 60 seconds or so, if the timeout is reached, the web server will return an empty response. And again, the web client immediately makes a request. And you can also have multiple in parallel running request responses like that as well. So it supports session attachment and resumption, which is important because we have this statelessness of the HTTP protocol, but you want to maintain your XPP session across requests and also across page loads. So this is done with session and request tokens that you kind of have to send with each request to maintain your session. And it requires a connection manager. The connection manager is basically a thing that sits between the XPP server and the HTTP client. It speaks HTTP to the HTTP client and it speaks XPP to the XPP server. So it's like a translating device for translating service. And it's built in with most XPP servers. You generally don't have to worry about it unless you want to support many different servers, then you might have to use a standalone one. The other technique is a web socket. Advantage of it is that it has less transport overhead. You only have to establish one connection per page load. You don't have to establish a new socket connection for every request that you do, for example, of HTTP, which can become expensive if you have TLS connections. It's bi-directional and it's basically emulating the TCP socket connection that you would have with XPP in normal circumstances, but at the application level, at the browser level. And it also has a quick session resumption. So if you reload the page, you can just quickly attach, so to speak, to your existing session. But that's in a XPP extension called 0198 stream management. If you implement that, then you get that. So that's front-end. Back-end, there's basically three ways that you might communicate between your web application, back-end, your web app, and XPP server. The one would be to use Bosch, again, that I just explained. Another one would be to kind of have some kind of built-in XPP client using an XPP library, where it would have to be then asynchronous, right? It would have to fulfill these requirements mentioned earlier. And a third way is to have HTTP calls between your web application and an XPP server. If the XPP server provides some kind of RESTful or JSON HTTP API, which a lot of them do. So the only reason why I know that people do Bosch communication between a back-end and XPP server is just for a technique called pre-binding, where you want to log in the user before the page loads so that you can kind of have one session. The user can log into your CMS or website or application, and you do the pre-binding where it on the back end establishes an XPP session so that the user doesn't have to maintain another set of credentials for the XPP server. There's a drawback to this, and that is that if you want to do this, you need to have the credentials in plain text of the XPP server, because you need to be able to log the user in. So there are other ways of doing this that I think in many cases are better. You could, for example, do some kind of token-based authentication where you sign tokens with some kind of private key, and the XPP server verifies that the token was signed with the right key and also has the right format. You could use various forms of external authentication whereby you hand over authentication, the XPP server hands over authentication to some kind of external database or website. So for example, you could let the XPP server authenticate against your own website. So in that way the user's credentials for your website are the same credentials for the XPP server. And they could also, if they have a mobile app that has XPP, they can use the website credentials to log in there and have chat and not have to worry about two sets of credentials. Or you can have some kind of external back end like LDAP, SQL, or so on. So two more reasons why you might want to share data between your web application back end and XPP server is you might have already some kind of concept of, let's say, conversations on your website where you are creating conversations in some kind of CMS or so on. And now you want to make these conversations real-time. So in that case, you might want to keep a hold of this kind of concept of conversations in your web application and then mirror it or replicate it to the XPP server. In this case, you really have to think about atomicity. In other words, when you are creating a so-called conversation and you have to correspondingly create a chat room in your XPP client, XPP server, excuse me, this has to happen as one atomic transaction so that it cannot be split up because otherwise you're going to have situations eventually where the data is not mirrored correctly. Another question you might have to ask yourself is where is the canonical store? If you're having it mirrored across two back ends, you probably want one of them to be the truth and eventually if something happens and you need to kind of regenerate the data, you have this one where you can kind of push it out back into, for example, the back end is your canonical store and you push out the data to the XPP server. Another case which is similar but not exactly is if you want to just have communication between the two servers but you don't want to store it on both of them. So a good example is let's say you have some kind of social networking features already in your website so you have some kind of social graph or a context list or whatever and you want to also present this context list in the context of XPP or if your real-time chat application or real-time chat part of your app, that would mean that you would want the XPP so-called contacts roster to have the same data so you can tell the XPP server to fetch this data from your web app and for ProCity XPP server, for example, there is a module for that which Matt Wilde, the creator of ProCity, wrote which I use and yeah, that's a good example of that. Then coming to ConverseJS, what is that? It's a chat application that runs on your browser, it uses StrobeJS which I just heard the Jetsy Meet people also use for their web app. You can use it as a standalone application at ConverseJS.org, that's kind of what it looks like, that's also the website. If you were to go there now you can log in, if you have an XPP account, you can also register a new account and use it. There's also a mobile version, I wouldn't recommend using it for mobile, there are mobile apps that are way better but if you are in a bind or for whatever reason you can also go to the mobile version of it and use it like that. It's translated, very well tested, it supports both Bosch and WebSocket. Bosch works very well by the way and it's actually what I use most of the time. It can be integrated into any website and mainly for three reasons. It's very customizable, configurable, so it has this link goes to the config settings page of Converse where you can see all the configuration settings and through this you can turn things on and off where you can configure how things work. You can also, the features are all implemented as plugins so you can take out any features and create a new build of the JavaScript build and therefore have create your customized yourself and of course also write your own plugins to add new features of the customized it and if you don't want to use plugins, if you just want to use the full build which is available via CDN you can also just disable them through white and black lists. The code is there but I haven't had tests and it's not released so that's what I'm saying coming soon. So let me show why or let me show that this is possible. This is Converse.js, the website itself so you can see it's like overlaid with that of course makes it much easier to integrate into a website because you can have any kind of design or whatever and you can just overlay these things of course you can start it yourself as well it's just HTML and CSS. Here's a full screen version I'm working on that's the same code base it's just different CSS and a small plugin with a little bit of JavaScript. It's not completely finished yet but it's getting there. Same one here it is in Reddit I can actually have it live as well so I made a little Chromium plugin which just loads the JavaScript files it's two it's one JavaScript file and one CSS file and it loads it in any website and you just then have chat so you know I'm just going to spam the summer chat room here it is running in Reddit I also have it and Tweetek it's basically any any website here's a little example of a CSS bug so generally you know there's little things like that that you might want to take a look at when you're integrating it yeah so there's that what I also this these slides are a website here I integrated into the slides as well this is a so-called embedded it's just a single chat room it's the chat room is called anonymous that's why it says anonymous there and you're also logging in anonymously luckily nobody has put anything inappropriate there and so it's running in the slides this is open source project I've gotten many bug bug fixes and pull requests over the years and I'm very grateful and thankful for all of those I'm very happy to get more people involved yeah there's there's really a lot to do here are all kinds of things that one could work on I'm seriously considering starting Google Summer of Code projects for OMEMO encryption and MIX MIX is like a new conversation protocol that is in the pipeline that's kind of basically being implemented now and yeah also designers I don't know if there's any any designers here but there's really a lot that could be work on and I'd be happy to work together with other people more on this there are also other software in a similar vein so there's two other libraries for example besides strove which stands IO and XMPP for the web stands IO is used in otok and in kaiwa kaiwa is a single page app I don't really I'm not going to go into detail there but I link to them you can check them out and you're welcome to compare all the different options and their strengths and and weaknesses and that's basically it these are my details if I cannot answer any questions now you're welcome to reach out to me my email address is also my XMPP handle and I'm happy to to answer any questions or to talk about anything yeah any I don't know if we have time we have three minutes yeah so I also have a moment now for questions if anybody has some a bit naive question for me I'm not so I don't know this thing so what are you doing it's different from slack let's say XMPP is a is a open standard standardized protocol that's also federated so it allows you you can run your own private XMPP server and then you could create your own slack kind of service one of the big advantages of XMPP is that you can connect it's like email so if I have my XMPP server and you have your XMPP server or you're using someone else's I can send you a message so it's not siloed like so so many of the commercial offerings besides that XMPP has certain ways of it expects things to be done that like certain concepts slack has helped to kind of make people think a new about how chat should work for example also with mobile connections and so on the idea that you are always in a conversation and always online not online but you're always part of a conversation is kind of something that is relatively recent before there was this idea like an IRC also that you join and then you're in or you're not but you're not like a member of a room even if you're not online so that's where MIX comes in it's MIX is partly I think a response to to innovation that has happened but it's so it's kind of like slack it's just generally free and open source and doesn't lock people in sorry that's my own yeah let's say mother most okay it's not about open source only I just want to know the functionality that you produce and give the people yeah so you could like because it's a communications protocol you can also use it for example for other kinds of signaling so to have devices talk to one another or to yeah we cannot take more questions we are super tight schedule okay sorry thanks Casey thank you