The state of the XMPP Community
Gultsch, Daniel
The Extensible Messaging and Presence Protocol is the foundation of a provider independent form of instant messaging. While XMPP - from a technical perspective - had some catching up to do in the last couple of years it is now ready to handle the vast majority of tasks a modern instant messaging solution is supposed to handle. (The process on how we got there has been documented in previous FrOSCon talks.) However an instant messaging system is only as good as it's implementations. This talk will look at the state of various open source implementations and at the broader XMPP community as a whole. A common theme of previous talks on XMPP has always been "We had this interesting technical problem, found a solution to it and implemented it into one client". (Un)fortunately the XMPP ecosystem is made of more than just one client. While catching up with modern extensions and features is slow in a system that is almost exclusively developed by volunteers, it is still happening. This talk will give an overview of what various XMPP projects have been doing (implementation wise) over the last ~12 month and will try to explain why some features have been adopted more quickly than others. It will also show the various ways the XMPP community has been trying to lower the barrier of entry for new developers and bringing the community closer together by organizing regular Sprints (Hackathons) and local Meetups. The talk will also look into recent efforts of the community to unify the user experience across multiple clients.
 Oh, and it's time. Yeah, thank you all for coming, even though apparently there's a very popular talk going on at the same time. So, yeah, thank you for choosing this one over the other one. This is not going to be a technical talk. If you want more technical insights into XMPP, I'll refer you to talks I gave in the past. You can find most of them on media.cccde, for example, by searching for XMPP or searching for my name. Some of them are also linked from the FrostCon schedule. I think that's okay, right? Yeah, instead, I want to talk more generally about the XMPP community, the events we organize and essentially how we develop software. And after that, I want to dive very briefly into some commercial uses of XMPP because that are things that you might not know as a regular user. Yeah, then we will simply go over a bunch of clients that are currently in active development, showcase some of them. And last but not least, I want to share some observations I made while working on XMPP. So it's not directly a summary from my talk, but more general things that I noticed. I wasn't quite sure how to refer to the group of people that I want to talk about. In previous talks, I used Ctam-Jabbar to refer to the network of publicly federating servers as opposed to XMPP protocol that can be used in all sorts of contexts. But I don't like that word very much anymore, partially because Cisco owns the trademark on that word. And yeah, so I wasn't really sure what to call that. I mean, noncommercial would be another term, but that also isn't a really good fit either because there are some commercially operated providers that are still part of that network and there are also clients that you have to pay for. So just note when I say open source community, I'm basically referring to people like you and I that are using Cpublicly federating servers. So let's begin by asking ourselves who uses XMPP? Basically in a federated system, we have no way of knowing who uses XMPP and that's a good thing. Most providers make a point in not storing things like the IP address and generally store as little data as necessary. And even if some public servers would publish that information, we don't account for the countless of personal and small office servers that fly entirely under the radar. However, if we knew that XMPP, for example, was over or underrepresented in a certain country, for example, we could learn from that and repeat what we do in successful countries and less successful ones and attempt to grow the community that way. So what these download stats from conversations show is that they pretty much confirm what I observe myself when talking to users or in our chat room or when looking at the users on the GitHub issue tracker. Also I made the observation that when I tell someone at a conference here in Germany like Frostconn on the KLS Communication Congress that I'm working on XMPP, that they do know what I'm talking about. They might not use it, they might not even like it, but they still have heard of XMPP. However, last year I was at a conference in Singapore and during the occasion hallway discussions I mentioned that I'm working on XMPP and nobody had a clue what I was talking about. Similarly, when I'm at the Google Summ of Code Mentor Summit in the United States, which had a pretty international audience, I also feel like I have to explain what XMPP is. So yeah, those stats pretty much confirm that observation. However, you have to know that the data is kind of problematic anyway because roughly only 25% of users get conversations from the Play Store and the rest use FDroid. And even that 25% is problematic because it's just a guess. Now if you look at the download stats from conversations legacy which is available for free on the Google Play Store, we see something interesting. So out of nowhere we suddenly see Indonesia on that list. But the rest of the list remains roughly the same. We have Russia on this list, we have Spain in the United States, we all saw them on the other list as well. I actually don't have a good explanation for that. Obviously, two years is a lot more money in Indonesia and more importantly, people in Indonesia might not have credit cards. But it's not like the free version would see an equal distribution worldwide. It's skewed towards Germany and then we just got Indonesia additionally on that list. And also Xabar which is also available for free which is an alternative client reported similar stats on Twitter that they also see like in Germany, Russia and Indonesia as they are top three countries. When we look at the Quixi stats, it's even more obvious. And that's kind of a sense because I only ever mentioned Quixi during the initial presentation I gave in Berlin and then it was mentioned by a German online magazine and by an offline computer magazine also in Germany. So it's kind of makes sense that we see that Germany has a lot of users. However, it also gives us a guideline on what we have to do to spread it over the rest of the globe and that's basically like telling users about it. So this data is highly problematic as well. So people gather the data, use only one probably fairly biased list of servers and also they looked at the A record not as the SFV record. So they basically looked at where the website is hosted not where the XMPP servers hosted. But still if there is at least some truth to that data, it also confirms what we are seeing in the other statistics. And also like if a vast majority of XMPP users are from Germany, it's natural to assume that they use and operate servers in Germany. Interestingly the people who published that data try to spin it into an argument on how XMPP isn't really federated because all the servers are in the same place. However to me it's just obvious that users pick servers close to them. Looking at the developers of XMPP, it becomes harder and easier at the same time. There's no central instance that would collect that data. The XMPP standards foundation has a list of members but that doesn't keep track of where they are from. But that's also ignoring that some developers are not registered with the XMPP standards foundation anyway. So what I did instead was go over the list of XMPP software on the XMPP arc list and like manually looked into a guitar profile pages or contact information on websites and stuff like that to collect that list. And again you see a lot of Europe, Germany and France in particular stood out and again like Russia and the United States. So lately many events are organized in the XMPP community and first and foremost that's the XSF summit, the main event basically where the open source and the non-open source people come together and discuss upcoming extensions and long term plans for the future of XMPP. This year discussions included better message archiving like storing messages and metadata like read information or delivery information together. We also talked about mix which is in some future going to replace a Mac as the group chat for the call. That's always a very intense two days because there are like 50 expert in that field sitting around one conference table and having very like in-depth conversations about like the innards of XMPP. Community organized events, we try to avoid the term hackathon because that was hijacked by the industry to mean something else. But it's usually developers coming together usually over a week and to learn from each other to rapid prototype things that might require like both server and client implementation just to be social and meet basically the people they have previously only known online. Actually, you found early attempts of sets that date back to 2013 but for a year now if you've been doing them on a fairly regular basis. Usually everyone could organize one themselves and we try to help you or guide you to organize a sprint yourself. How to on our wiki and we also will give you visibility. There's a marketing team within the XSF and when you want to organize a sprint, we will help you like get the word out. But the vast majority of sprints this year or last year have been organized by one person. Thank you, Pep. You're not here. Thank you. But lately after like publishing the how to and stuff like basically everyone would have the power to do that themselves and if there are any questions, we will still help you or even like attend your sprint. Also that's like more informal. There are meetups. There are monthly meetings. It's just people coming together also users not just developers but also XMPP users. The Berlin meetup is going for several years now and there are times where just two people would show up but they kept it going and just continued doing it. And now there are like 10 to 20 people showing up. In Dresden where I'm currently living, we started one like three months ago and there we have like five to 10 people coming. The Berlin and Dresden ones are next week and the Munich one is the week after that. So if you're living in one of the cities, feel free to come there. Yeah. And also we are attending conferences. For example, the XSF themselves, they have a booth at FOSDEM because FOSDEM is right after the XMPP summit and that's kind of the most official one. You can get the official merch, you can buy an XMPP hoodie and get bottle openers and stickers. In recent history, we also attended the CCC events and we are going to attend camp in two weeks, I guess. However, those resemble more sprints and booths at normal conferences. However, you can still come by and talk to us or get stickers and stuff like that. And yeah, of course, we also have a booth here at Frostcon, which was actually very well visited today, but feel free to come by tomorrow if you haven't already today. Yeah. Let's look into some improvements that happen to the ecosystem itself. That's not like improvements to servers or clients, but to the general ecosystem that kind of improves the user experience for users wanting to use XMPP. So that's one of the coolest projects that have emerged in the last year. It will basically find you open conferences or open group chat to talk to other people and what it does, it crawls a vast number of servers and then generates a list of public rooms ordered by the number of participants so that you are finding the good ones first and it also allows you to search. Yeah, usually that's a website, but it also has an API so that you can integrate that into your client and so users of your client would automatically find someone to talk to with their new to XMPP, for example. Basically it's a centralized service that would either collect your IP address or could potentially collect your IP address or your Java ID depending on whether you are accessing the API over HTTP or XMPP, but yeah, I guess that's just what you have to live with. So there's no other way to solve that problem. And a nice little project is the Mac badge that if you want to link your XMPP group chat from your website or from your project's GitHub page, you can use that instead and it integrates nicely into the list of badges you might have anywhere and displays how many people are currently in that list and you can also link it automatically to that list so if people have an XMPP client installed they can click that badge and we'll get right into that group chat. Also while we are on the topic of badges, if you operate a public XMPP service there's another badge that you can stick on your website and that uses information generated by status.conversations.im and that's basically like a monitoring tool that will check if your XMPP server is online and available but it needs credentials to log in so you would have to go to status.conversations.im and enter credentials like test credentials obviously for your server and then like so that later you could stick that badge on your website if you want to. So one of the arguments you hear often against XMPPs is that there are too many extensions and as an implementer you don't know what to implement and as a user you don't know what client to download and there's certainly some truth to that. We currently have more than 400 extensions so to counteract that for a while we had so-called compliance suite which are basically meant for developers to tell them implement those 10 extensions and everything will be fine and there are different profiles for example the web client might need to implement a slightly different set of extensions or then let's say mobile client. And recently we made some efforts to also expose that information to end users. A client that is compliant to a certain profile can show a badge to their users and then users can specifically look for compliant clients sort of a seal of approval. Ideally it would also act as an incentive for developers to implement the compliance profiles. Currently there's a design competition going on on how that seal of approval might look like and so as a client developer you even know if you implemented one of the compliance suites and just show the badge. There could also possibly be self-assessment tests in the future where you basically check off every extension that you've implemented and it will tell you what profile you implemented and there's a prototype for that on Bitbucket. Or even better you could put all the extensions you implemented in a special XML file together with some additional information about your project and then the xmpp.org website that lists different clients could automatically determine that based off the XML file. But if you make the information machine readable you can also do the reverse. So when viewing XSAP you could also see what software implements that specific extension. So actually the vast majority of servers these days is compliant. So it's usually just a case of whether or not your service up to date and configured correctly and so there's the compliance tester. There's not meant to check out server software but more check out if you as a provider have configured everything correctly and it also has like email notifications and direct access to help if you're missing something. So if you're checking your own server and it detects that something is missing to be fully compliant it will automatically tell you oh you need to change that in your configuration file to fix the issue or update your server or whatever. So recently there have also been some attempts to unify the UX across different clients. That doesn't mean having the same UI on every client but at least some common vocabulary for example. For example what to call a group chat or even what to call the JAB ID or should we call it XMPP address. So yeah there was one sprint recently where specifically only like tried to develop that common vocabulary and tried to discuss how we can make the clients more uniform. Also there's a neat little extension called consistent color generation. What it does is basically that if one user has a red avatar like an automatically generated avatar on one client it will also have the same shade of red on the other client. So that will be easier to recognize the user across different clients. If my friend Peter is green on one client he will also be green on the other client. So on the topic of growing the communities that's twofold on one hand we obviously want to attract more users but we also desperately need more developers. A vast majority of developers only work part time on XMPP and that in turn means to compensate for that we need to attract more developers. Growing the user base is simple but not easy. Basically what we do is we need to spread the word for example that graph is the quick seed download on the Play Store after it received publicity on a German computer magazine and this also ties back to the beginning of the talk. And basically the reason I believe that kind of says it's significantly more successful in Germany is that we get some news coverage here in Germany while we get no news coverage in other countries. Yeah, and like I said we also recognize that we need more developers. Proper companies have dedicated people for that so called developer advocates that go to every conference in the world and tell everyone how great their tooling is. And yeah, it's also a great documentation to make it easier for people and we all have to do that ourselves. However, we identified the need for it and we're trying to set aside some time to do all that. Talking about commercial usage of XMPP is always a bit challenging because people are often oddly secretive about things and when I'm working on commercial projects I'm usually under NDA most of the time. So for me it's actually easier to talk about other people's projects. However, I still want to give you some examples. One funny example I learned about recently that a fashion label was using is it because apparently when you buy expensive fashion these days you're not going into a store or like an even an online store but you buy it on Instagram or Snapchat and then they were using XMPP to find all that communication from the different channels into their back end. Yeah, also NATO and a lot of government agencies are using XMPP. Usually they use special clients from companies that specifically cater to that market and then those clients have special features like marking messages top secret or only for Germany and then they have basically XMPP firewalls sitting in between for example the UK Army and the German Army that filters out messages based on that criteria. But I also know at least one intelligence agency that uses vanilla conversations with vanilla eJabadi. So yeah, but you might ask yourself why what do we have, I mean what's in fast if NATO uses XMPP right, they're using their own clients so what's in fast and it's a lot of implementation experience so like on the XSF summit roughly half of them are working like in those closed source projects and when they implement MIX for example which again is the successor to mark for group chat they might not able to share the implementation but they are definitely able to share the experience and then we can learn from that. And also a lot of the big servers are backed by companies who make money with those type of customers and that's why a lot of the servers actually relatively up to date with all the extensions. So yeah, let's talk about clients. So there's Converse.js and that's not just the best web client you can get but also one of the best clients overall. It's fairly actively developed. It has had two major releases over the last 12 months and counters of mine and bug fix releases. Last year the developer actually worked full time on that and now here's a job where he's allowed to work on Converse and yeah, last year it received a support for HTTP upload and the latest version which was actually released this week got support for stream management which means you can switch over from Bosch to WebSockets which should be way more efficient. Moving also interesting because it's one of the few web clients and it's actually more of a social network with chat capabilities. And yeah, I'm mentioning it here because A it's like doing a little bit, things a little bit different, it's more of a social network and that shows you that you can also use XMPP to develop that but it was also the first client that implemented emoji reactions which are basically like sums up to a message for example and that's like also the new hotness in the XMPP community and stuff that other clients are currently working on as well. It does require PHP backend for proxying and caching things so it doesn't talk to you XMPP server directly so if you want to set it up it's a little bit more complicated to do than for example just running Converse which is just JavaScript that you can deliver on a website. Yeah, so Dino uses GTK on paper platform independent, got Domemo on HTTP upload about a year ago also has support for PGP which is interesting because it's one of the newer clients that like deliberately implemented PGP even though that's a fairly old extensions. Progress is slow but steady. Google sum of code student is currently working on Jingle file transfer which you would need if you want to transmit really large files that are not covered by HTTP upload because usually on HTTP upload there's a file size limit and yeah. Then Dino if you're trying to transmit a file that is larger than what HTTP upload allows it will automatically fall back to basically peer-to-peer file transfer which is the same that conversations is doing as well. Yeah it's my personal daily driver however there's no official release yet which is like super annoying because like people on macOS and Windows have to compile it themselves. But it still has a very clean UI and also basic features so people still flock to it even though it doesn't have an official release. So there's Gatium that's basically the polar opposite to Dino, it has all the XMPP features like all of them and in parts the UI is a little bit cluttered and the code base is the mess. It's a pretty old client, the current maintainer I think is the third maintainer of that client. However the maintainer is actively working on cleaning it up and cleaning up both the code base and the UI and he's also very involved in the community and interesting in supporting new things. For example the current master branch has support for the Mac search that I mentioned earlier and he's also like I said trying to clean up the UI and become a little bit more like Dino in that way but I'm afraid it might be difficult to shake off the preconception of cluttered UI even if it will improve in the future. So yeah let's see how that will go. So Poetio that's basically the Gatium of text UI's, it has plugins for almost everything except unfortunately Omimo but it is in the works right here but it has plugins for HTTP upload, emoji reactions and yeah everything. There's one for code like highlighting and rendering avatars even though it's technically a console client and yeah it's kind of the prosody of clients, it's pretty easy to prototype it because it's written in Python and everyone knows at least a little bit of Python. Yeah then there's profanity which is also like a console client, noteworthy because it got Omimo support just recently and it also has support for HTTP upload. So yeah there's UWPX, interesting because usually Windows support for XPB clients is always a second class citizen because most XPB developers are Linux or whatever and so that's interesting because that's a dedicated Windows client and it uses the universal Windows platform toolkit which allows you to write the same software for different platforms so it will run on your Windows and on your Xbox for example and technically it would also run on Windows phones which would be super cool if Microsoft wouldn't have stopped making those. Yeah it's also interesting because it has some basic support for Omimo but virtually nothing else so they prioritized Omimo over HTTP upload and stream management and MAM and everything and it's still very alpha but yeah interesting because of all the other reasons. So this Kydem which also has an interesting concept because it uses QT and the KDE Kirigami library to be truly platform independent. So on paper it would work on your Android phone, on your MacOS, on KDE. However it doesn't really feel native on Android. For example the file slash image picker uses a built in file browser that can only access files within the Kydem space so you can share the database of Kydem but nothing else because you don't have permissions to access anything else. It also doesn't stay connected in the background on Android. I'm not sure if they're able to fix it or yeah but it supports things like HTTP upload as you can see in the screenshot obviously but it doesn't have support for group chats just yet and no support for Omimo however both of them are planned for the next two milestones. Chat secure yeah not much happened in the last year of Chat secure. A couple of maintenance releases where they bumped the versions of libraries. He's currently working on porting it to MacOS. This is a project catalyst thing which allows you to port an iOS app to MacOS and he's currently working on that. However it's still probably one of the best options if you're using iOS and it supports HTTP upload and Omimo. So there's Monal another iOS client that has actually been around for a while but wasn't very active for quite some time. However the development pace has increased lately and it also has support for Omimo and it doesn't have support for group chat though. But since all clients on iOS are less than ideal so yeah I mentioned all of that so you can pick and choose. So obviously there's conversations and for the most part of 2019 it was focused on stability rather than chasing new features and I only did a few things like incorporating the changes from the UX sprint where I made it to use the common vocabulary that we came up with and it also gained support for the Mac search and backups is also a feature that it got this year. Yeah, however I do have a roadmap towards conversations 3.0 and note that it's definitely not a timeline just the plans that I have for the future. However I have secured funding for voice over IP basically jingle audio and video calls and that's going to be the next thing I'll be working on. Yeah, there's Qixi. That's basically a spin off of conversations not a fork but something that's developed in the same source tree and that's basically conversations but you can on-bottom your phone number and it would automatically find other Qixi users based on their phone number. And you can also chat with regular XMPP users on that and Qixi users can also manually add other XMPP addresses or like as a normal XMPP user you can add a Qixi user by knowing the phone number and typing phone number at Qixi.i am I talking to that as if it were a regular XMPP account which it is. So to make it even easier for Qixi users you could also add your phone number and XMPP address to the so-called Qixi directory and that will enable Qixi users to discover your real XMPP address based on your phone number. And so basically like the tagline is that conversations is for you and Qixi is for your non-nerd friends. And I've heard stories where people send the Qixi place the link to their grandmother and like two minutes later they got contacted on XMPP because like discovery and sign up is so easy. So if you are thinking about giving Qixi to your non-nerd friends you probably want to enter your phone number and your XMPP address into the Qixi directory and with that code you can also do that for free. Basically it's five bucks per entry and that's used to cross finance Qixi because like Qixi is available for free also to make the onboarding easier and yeah. So that's how we usually try to fund the server but yeah. If you want to do it now you can do it for free with that code. Another interesting set of clients are the clients that are formerly known as Tiger's Messenger and that could have actually been interesting because it's a branding thing. So if they would have kept the name across all platforms you could just theoretically tell people just download Tiger's Messenger and then no matter what platform they are currently on it would just work out. However apparently it's what's like completely separate apps and then their customers were very confused that even though it's all the Tiger's Messenger they're like different feature sets and yeah apparently for the company that does that there's also a little incentive to make them to gain feature parity between them because usually it's a server manufacturing industry and to them Tiger's and the other clients is just a tech demo to show their customers what XMPP is capable of and so they split it off and gave like each client for each platform a different name. So the clients for iOS and Mac OS, Syskin and Beagle are probably the most interesting ones that are kind of feature complete that support HTTP upload and a Mimo and even Jingle calls and on those platforms the competition isn't really good either so they are definitely interesting to check out. Yeah Xsabra that's a similar situation like that that is also one client that on papers available on different platforms. It used to be an Android client for a long time but they also have a web client and they are also working on an iOS client which is currently in a closed beta and there's no public source code yet. So yeah that's another contender in the unified brand approach but to be honest it's a little bit worrisome because apparently they don't like a lot of these extensions like they don't like Macs, they don't like stream management and they always write on the XMP standards mainly so they don't like the extensions and they have come up with something that is way way better but it's only documented in Russian and yeah so I'm not sure what their future plans are so they might actually develop that into something that's not actually compatible with XMPP anymore but we'll see. It's definitely worth like keeping an eye on. So lessons learned that's not actually probably not actually lessons in that I don't have a conclusion on that but more like observations I made. For example there's a thing of Jingle file transfer versus HTTP upload. So Jingle is a fairly complex protocol to negotiate peer-to-peer sessions. It can be used to negotiate voice of IP sessions but also file transfer. Actually everything that can be sent peer-to-peer. It's very powerful but it's also very complex. In a way it's a protocol within a protocol and people love it because in theory you can use it to send large files between people and the server is not involved at all. However due to its complexity it only has three finished implementations and every time I did interrupt testing with one of the other implementations I discovered bugs in either conversations or the other side. On the other hand you have something like HTTP upload where files are not exchanged directly but stored temporarily on the XMPP server and it gets the job done and anyone can implement that in the afternoon. On the other hand you have something like Omimo which is also like a fairly complicated extensions as well but now it's actually widely implemented. Some clients like the Windows universal platform thing I told you about even gave it a higher priority to implement than some other more essential extensions. However there isn't really good alternative available to Omimo and users really want to use entrant encryption. So even if that's not a really perfect extension it will still get implemented. That already concludes my talk. Are there any questions? Yes, Isie. Hello. I can your repeat your question. I guess. Yeah. Does the Qixi financing, your business model, does it actually work? Or are you paying for Qixi? Good question. No, it doesn't really. I mean, I came up with that elaborate business model because sending SMS is really expensive. I was dreaming of a thousand registrations a day or a month or whatever, right? And then I would run into very high costs to send those SMS. So I was desperately looking for a business model because I couldn't pay for a thousand SMS a month myself. But in reality, I only get like a hundred SMS a month or whatever, and I can easily pay for that myself. And I cross-finance that with what I get from the conversations revenue on the Google Play Store or a few entries we do see on the directory. But no, currently the entries in the directory are not paying for the server, but that's still fine because I'm making money off of conversations on the Play Store and I can just cross-finance that way. And a second question is what if other developers would create a similar onboarding experience like Qixi and would you ask them to provide an own directory? Or would you like to federate? I mean, it may be confusing if every app has its own directory. Yeah, good question as well. So I mean, it depends a little bit on what they want. If they wanted to do that, the source code for the Qixi directory is open source and they could just combine that with an eJab ad and just do their own thing. But I could also imagine that, for example, if you see chat secure developer want to do Qixi for iOS and just use the same address space that they could just use my directory and my server. It might be open for that. I mean, it's a little bit challenging. I wouldn't really want anyone to use it without telling me even though they could. I mean, the API is even documented and everything. But I'm a little bit afraid of running into the problems that I briefly mentioned with Tigers that you have two different apps, essentially, that are called the same, both called Qixi, but they are behaving very differently. Not having a future priority or then someone joins the chat room. I have a problem with Qixi. I can't send files and you first have to ask back what platform are you using because they are behaving that differently. But yeah, if someone would write a really good iOS client that would be on par with conversations, that would be totally open for them to just use the same domain. Okay. I guess no more questions. Then thank you again.
 Oh, and it's time.  Yeah, thank you all for coming, even though apparently there's a very popular talk going  on at the same time.  So, yeah, thank you for choosing this one over the other one.  This is not going to be a technical talk.  If you want more technical insights into XMPP, I'll refer you to talks I gave in the past.  You can find most of them on media.cccde, for example, by searching for XMPP or searching  for my name.  Some of them are also linked from the FrostCon schedule.  I think that's okay, right?  Yeah, instead, I want to talk more generally about the XMPP community, the events we organize  and essentially how we develop software.  And after that, I want to dive very briefly into some commercial uses of XMPP because  that are things that you might not know as a regular user.  Yeah, then we will simply go over a bunch of clients that are currently in active development,  showcase some of them.  And last but not least, I want to share some observations I made while working on XMPP.  So it's not directly a summary from my talk, but more general things that I noticed.  I wasn't quite sure how to refer to the group of people that I want to talk about.  In previous talks, I used Ctam-Jabbar to refer to the network of publicly federating  servers as opposed to XMPP protocol that can be used in all sorts of contexts.  But I don't like that word very much anymore, partially because Cisco owns the trademark  on that word.  And yeah, so I wasn't really sure what to call that.  I mean, noncommercial would be another term, but that also isn't a really good fit either  because there are some commercially operated providers that are still part of that network  and there are also clients that you have to pay for.  So just note when I say open source community, I'm basically referring to people like you  and I that are using Cpublicly federating servers.  So let's begin by asking ourselves who uses XMPP?  Basically in a federated system, we have no way of knowing who uses XMPP and that's a  good thing.  Most providers make a point in not storing things like the IP address and generally store  as little data as necessary.  And even if some public servers would publish that information, we don't account for the  countless of personal and small office servers that fly entirely under the radar.  However, if we knew that XMPP, for example, was over or underrepresented in a certain  country, for example, we could learn from that and repeat what we do in successful countries  and less successful ones and attempt to grow the community that way.  So what these download stats from conversations show is that they pretty much confirm what  I observe myself when talking to users or in our chat room or when looking at the users  on the GitHub issue tracker.  Also I made the observation that when I tell someone at a conference here in Germany like  Frostconn on the KLS Communication Congress that I'm working on XMPP, that they do know  what I'm talking about.  They might not use it, they might not even like it, but they still have heard of XMPP.  However, last year I was at a conference in Singapore and during the occasion hallway  discussions I mentioned that I'm working on XMPP and nobody had a clue what I was talking  about.  Similarly, when I'm at the Google Summ of Code Mentor Summit in the United States, which  had a pretty international audience, I also feel like I have to explain what XMPP is.  So yeah, those stats pretty much confirm that observation.  However, you have to know that the data is kind of problematic anyway because roughly  only 25% of users get conversations from the Play Store and the rest use FDroid.  And even that 25% is problematic because it's just a guess.  Now if you look at the download stats from conversations legacy which is available for  free on the Google Play Store, we see something interesting.  So out of nowhere we suddenly see Indonesia on that list.  But the rest of the list remains roughly the same.  We have Russia on this list, we have Spain in the United States, we all saw them on the  other list as well.  I actually don't have a good explanation for that.  Obviously, two years is a lot more money in Indonesia and more importantly, people in  Indonesia might not have credit cards.  But it's not like the free version would see an equal distribution worldwide.  It's skewed towards Germany and then we just got Indonesia additionally on that list.  And also Xabar which is also available for free which is an alternative client reported  similar stats on Twitter that they also see like in Germany, Russia and Indonesia as they  are top three countries.  When we look at the Quixi stats, it's even more obvious.  And that's kind of a sense because I only ever mentioned Quixi during the initial presentation  I gave in Berlin and then it was mentioned by a German online magazine and by an offline  computer magazine also in Germany.  So it's kind of makes sense that we see that Germany has a lot of users.  However, it also gives us a guideline on what we have to do to spread it over the rest of  the globe and that's basically like telling users about it.  So this data is highly problematic as well.  So people gather the data, use only one probably fairly biased list of servers and also they  looked at the A record not as the SFV record.  So they basically looked at where the website is hosted not where the XMPP servers hosted.  But still if there is at least some truth to that data, it also confirms what we are  seeing in the other statistics.  And also like if a vast majority of XMPP users are from Germany, it's natural to assume  that they use and operate servers in Germany.  Interestingly the people who published that data try to spin it into an argument on how  XMPP isn't really federated because all the servers are in the same place.  However to me it's just obvious that users pick servers close to them.  Looking at the developers of XMPP, it becomes harder and easier at the same time.  There's no central instance that would collect that data.  The XMPP standards foundation has a list of members but that doesn't keep track of where  they are from.  But that's also ignoring that some developers are not registered with the XMPP standards  foundation anyway.  So what I did instead was go over the list of XMPP software on the XMPP arc list and  like manually looked into a guitar profile pages or contact information on websites and  stuff like that to collect that list.  And again you see a lot of Europe, Germany and France in particular stood out and again  like Russia and the United States.  So lately many events are organized in the XMPP community and first and foremost that's  the XSF summit, the main event basically where the open source and the non-open source people  come together and discuss upcoming extensions and long term plans for the future of XMPP.  This year discussions included better message archiving like storing messages and metadata  like read information or delivery information together.  We also talked about mix which is in some future going to replace a Mac as the group  chat for the call.  That's always a very intense two days because there are like 50 expert in that field sitting  around one conference table and having very like in-depth conversations about like the  innards of XMPP.  Community organized events, we try to avoid the term hackathon because that was hijacked  by the industry to mean something else.  But it's usually developers coming together usually over a week and to learn from each  other to rapid prototype things that might require like both server and client implementation  just to be social and meet basically the people they have previously only known online.  Actually, you found early attempts of sets that date back to 2013 but for a year now  if you've been doing them on a fairly regular basis.  Usually everyone could organize one themselves and we try to help you or guide you to organize  a sprint yourself.  How to on our wiki and we also will give you visibility.  There's a marketing team within the XSF and when you want to organize a sprint, we will  help you like get the word out.  But the vast majority of sprints this year or last year have been organized by one person.  Thank you, Pep.  You're not here.  Thank you.  But lately after like publishing the how to and stuff like basically everyone would  have the power to do that themselves and if there are any questions, we will still help  you or even like attend your sprint.  Also that's like more informal.  There are meetups.  There are monthly meetings.  It's just people coming together also users not just developers but also XMPP users.  The Berlin meetup is going for several years now and there are times where just two people  would show up but they kept it going and just continued doing it.  And now there are like 10 to 20 people showing up.  In Dresden where I'm currently living, we started one like three months ago and there  we have like five to 10 people coming.  The Berlin and Dresden ones are next week and the Munich one is the week after that.  So if you're living in one of the cities, feel free to come there.  Yeah.  And also we are attending conferences.  For example, the XSF themselves, they have a booth at FOSDEM because FOSDEM is right  after the XMPP summit and that's kind of the most official one.  You can get the official merch, you can buy an XMPP hoodie and get bottle openers and  stickers.  In recent history, we also attended the CCC events and we are going to attend camp in  two weeks, I guess.  However, those resemble more sprints and booths at normal conferences.  However, you can still come by and talk to us or get stickers and stuff like that.  And yeah, of course, we also have a booth here at Frostcon, which was actually very  well visited today, but feel free to come by tomorrow if you haven't already today.  Yeah.  Let's look into some improvements that happen to the ecosystem itself.  That's not like improvements to servers or clients, but to the general ecosystem that  kind of improves the user experience for users wanting to use XMPP.  So that's one of the coolest projects that have emerged in the last year.  It will basically find you open conferences or open group chat to talk to other people  and what it does, it crawls a vast number of servers and then generates a list of public  rooms ordered by the number of participants so that you are finding the good ones first  and it also allows you to search.  Yeah, usually that's a website, but it also has an API so that you can integrate that  into your client and so users of your client would automatically find someone to talk to  with their new to XMPP, for example.  Basically it's a centralized service that would either collect your IP address or could  potentially collect your IP address or your Java ID depending on whether you are accessing  the API over HTTP or XMPP, but yeah, I guess that's just what you have to live with.  So there's no other way to solve that problem.  And a nice little project is the Mac badge that if you want to link your XMPP group chat  from your website or from your project's GitHub page, you can use that instead and it integrates  nicely into the list of badges you might have anywhere and displays how many people are currently  in that list and you can also link it automatically to that list so if people have an XMPP client  installed they can click that badge and we'll get right into that group chat.  Also while we are on the topic of badges, if you operate a public XMPP service there's  another badge that you can stick on your website and that uses information generated by status.conversations.im  and that's basically like a monitoring tool that will check if your XMPP server is online  and available but it needs credentials to log in so you would have to go to status.conversations.im  and enter credentials like test credentials obviously for your server and then like so  that later you could stick that badge on your website if you want to.  So one of the arguments you hear often against XMPPs is that there are too many extensions  and as an implementer you don't know what to implement and as a user you don't know  what client to download and there's certainly some truth to that.  We currently have more than 400 extensions so to counteract that for a while we had  so-called compliance suite which are basically meant for developers to tell them implement  those 10 extensions and everything will be fine and there are different profiles for  example the web client might need to implement a slightly different set of extensions or  then let's say mobile client.  And recently we made some efforts to also expose that information to end users.  A client that is compliant to a certain profile can show a badge to their users and then users  can specifically look for compliant clients sort of a seal of approval.  Ideally it would also act as an incentive for developers to implement the compliance  profiles.  Currently there's a design competition going on on how that seal of approval might look  like and so as a client developer you even know if you implemented one of the compliance  suites and just show the badge.  There could also possibly be self-assessment tests in the future where you basically check  off every extension that you've implemented and it will tell you what profile you implemented  and there's a prototype for that on Bitbucket.  Or even better you could put all the extensions you implemented in a special XML file together  with some additional information about your project and then the xmpp.org website that  lists different clients could automatically determine that based off the XML file.  But if you make the information machine readable you can also do the reverse.  So when viewing XSAP you could also see what software implements that specific extension.  So actually the vast majority of servers these days is compliant.  So it's usually just a case of whether or not your service up to date and configured  correctly and so there's the compliance tester.  There's not meant to check out server software but more check out if you as a provider have  configured everything correctly and it also has like email notifications and direct access  to help if you're missing something.  So if you're checking your own server and it detects that something is missing to be  fully compliant it will automatically tell you oh you need to change that in your configuration  file to fix the issue or update your server or whatever.  So recently there have also been some attempts to unify the UX across different clients.  That doesn't mean having the same UI on every client but at least some common vocabulary  for example.  For example what to call a group chat or even what to call the JAB ID or should we call  it XMPP address.  So yeah there was one sprint recently where specifically only like tried to develop that  common vocabulary and tried to discuss how we can make the clients more uniform.  Also there's a neat little extension called consistent color generation.  What it does is basically that if one user has a red avatar like an automatically generated  avatar on one client it will also have the same shade of red on the other client.  So that will be easier to recognize the user across different clients.  If my friend Peter is green on one client he will also be green on the other client.  So on the topic of growing the communities that's twofold on one hand we obviously want  to attract more users but we also desperately need more developers.  A vast majority of developers only work part time on XMPP and that in turn means to compensate  for that we need to attract more developers.  Growing the user base is simple but not easy.  Basically what we do is we need to spread the word for example that graph is the quick  seed download on the Play Store after it received publicity on a German computer magazine and  this also ties back to the beginning of the talk.  And basically the reason I believe that kind of says it's significantly more successful  in Germany is that we get some news coverage here in Germany while we get no news coverage  in other countries.  Yeah, and like I said we also recognize that we need more developers.  Proper companies have dedicated people for that so called developer advocates that go  to every conference in the world and tell everyone how great their tooling is.  And yeah, it's also a great documentation to make it easier for people and we all have  to do that ourselves.  However, we identified the need for it and we're trying to set aside some time to do  all that.  Talking about commercial usage of XMPP is always a bit challenging because people are  often oddly secretive about things and when I'm working on commercial projects I'm usually  under NDA most of the time.  So for me it's actually easier to talk about other people's projects.  However, I still want to give you some examples.  One funny example I learned about recently that a fashion label was using is it because  apparently when you buy expensive fashion these days you're not going into a store or  like an even an online store but you buy it on Instagram or Snapchat and then they were  using XMPP to find all that communication from the different channels into their back  end.  Yeah, also NATO and a lot of government agencies are using XMPP.  Usually they use special clients from companies that specifically cater to that market and  then those clients have special features like marking messages top secret or only for Germany  and then they have basically XMPP firewalls sitting in between for example the UK Army  and the German Army that filters out messages based on that criteria.  But I also know at least one intelligence agency that uses vanilla conversations with  vanilla eJabadi.  So yeah, but you might ask yourself why what do we have, I mean what's in fast if NATO  uses XMPP right, they're using their own clients so what's in fast and it's a lot of implementation  experience so like on the XSF summit roughly half of them are working like in those closed  source projects and when they implement MIX for example which again is the successor to  mark for group chat they might not able to share the implementation but they are definitely  able to share the experience and then we can learn from that.  And also a lot of the big servers are backed by companies who make money with those type  of customers and that's why a lot of the servers actually relatively up to date with all the  extensions.  So yeah, let's talk about clients.  So there's Converse.js and that's not just the best web client you can get but also one  of the best clients overall.  It's fairly actively developed.  It has had two major releases over the last 12 months and counters of mine and bug fix  releases.  Last year the developer actually worked full time on that and now here's a job where he's  allowed to work on Converse and yeah, last year it received a support for HTTP upload  and the latest version which was actually released this week got support for stream management  which means you can switch over from Bosch to WebSockets which should be way more efficient.  Moving also interesting because it's one of the few web clients and it's actually more  of a social network with chat capabilities.  And yeah, I'm mentioning it here because A it's like doing a little bit, things a little  bit different, it's more of a social network and that shows you that you can also use XMPP  to develop that but it was also the first client that implemented emoji reactions which  are basically like sums up to a message for example and that's like also the new hotness  in the XMPP community and stuff that other clients are currently working on as well.  It does require PHP backend for proxying and caching things so it doesn't talk to you XMPP  server directly so if you want to set it up it's a little bit more complicated to do  than for example just running Converse which is just JavaScript that you can deliver on  a website.  Yeah, so Dino uses GTK on paper platform independent, got Domemo on HTTP upload about a year ago  also has support for PGP which is interesting because it's one of the newer clients that  like deliberately implemented PGP even though that's a fairly old extensions.  Progress is slow but steady.  Google sum of code student is currently working on Jingle file transfer which you would need  if you want to transmit really large files that are not covered by HTTP upload because  usually on HTTP upload there's a file size limit and yeah.  Then Dino if you're trying to transmit a file that is larger than what HTTP upload allows  it will automatically fall back to basically peer-to-peer file transfer which is the same  that conversations is doing as well.  Yeah it's my personal daily driver however there's no official release yet which is like  super annoying because like people on macOS and Windows have to compile it themselves.  But it still has a very clean UI and also basic features so people still flock to it  even though it doesn't have an official release.  So there's Gatium that's basically the polar opposite to Dino, it has all the XMPP features  like all of them and in parts the UI is a little bit cluttered and the code base is  the mess.  It's a pretty old client, the current maintainer I think is the third maintainer of that client.  However the maintainer is actively working on cleaning it up and cleaning up both the  code base and the UI and he's also very involved in the community and interesting in supporting  new things.  For example the current master branch has support for the Mac search that I mentioned earlier  and he's also like I said trying to clean up the UI and become a little bit more like  Dino in that way but I'm afraid it might be difficult to shake off the preconception  of cluttered UI even if it will improve in the future.  So yeah let's see how that will go.  So Poetio that's basically the Gatium of text UI's, it has plugins for almost everything  except unfortunately Omimo but it is in the works right here but it has plugins for HTTP  upload, emoji reactions and yeah everything.  There's one for code like highlighting and rendering avatars even though it's technically  a console client and yeah it's kind of the prosody of clients, it's pretty easy to prototype  it because it's written in Python and everyone knows at least a little bit of Python.  Yeah then there's profanity which is also like a console client, noteworthy because  it got Omimo support just recently and it also has support for HTTP upload.  So yeah there's UWPX, interesting because usually Windows support for XPB clients is  always a second class citizen because most XPB developers are Linux or whatever and so  that's interesting because that's a dedicated Windows client and it uses the universal Windows  platform toolkit which allows you to write the same software for different platforms  so it will run on your Windows and on your Xbox for example and technically it would  also run on Windows phones which would be super cool if Microsoft wouldn't have stopped  making those.  Yeah it's also interesting because it has some basic support for Omimo but virtually  nothing else so they prioritized Omimo over HTTP upload and stream management and MAM  and everything and it's still very alpha but yeah interesting because of all the other  reasons.  So this Kydem which also has an interesting concept because it uses QT and the KDE Kirigami  library to be truly platform independent.  So on paper it would work on your Android phone, on your MacOS, on KDE.  However it doesn't really feel native on Android.  For example the file slash image picker uses a built in file browser that can only access  files within the Kydem space so you can share the database of Kydem but nothing else because  you don't have permissions to access anything else.  It also doesn't stay connected in the background on Android.  I'm not sure if they're able to fix it or yeah but it supports things like HTTP upload  as you can see in the screenshot obviously but it doesn't have support for group chats  just yet and no support for Omimo however both of them are planned for the next two milestones.  Chat secure yeah not much happened in the last year of Chat secure.  A couple of maintenance releases where they bumped the versions of libraries.  He's currently working on porting it to MacOS.  This is a project catalyst thing which allows you to port an iOS app to MacOS and he's currently  working on that.  However it's still probably one of the best options if you're using iOS and it supports  HTTP upload and Omimo.  So there's Monal another iOS client that has actually been around for a while but wasn't  very active for quite some time.  However the development pace has increased lately and it also has support for Omimo and  it doesn't have support for group chat though.  But since all clients on iOS are less than ideal so yeah I mentioned all of that so you  can pick and choose.  So obviously there's conversations and for the most part of 2019 it was focused on stability  rather than chasing new features and I only did a few things like incorporating the changes  from the UX sprint where I made it to use the common vocabulary that we came up with  and it also gained support for the Mac search and backups is also a feature that it got  this year.  Yeah, however I do have a roadmap towards conversations 3.0 and note that it's definitely  not a timeline just the plans that I have for the future.  However I have secured funding for voice over IP basically jingle audio and video calls  and that's going to be the next thing I'll be working on.  Yeah, there's Qixi.  That's basically a spin off of conversations not a fork but something that's developed  in the same source tree and that's basically conversations but you can on-bottom your phone  number and it would automatically find other Qixi users based on their phone number.  And you can also chat with regular XMPP users on that and Qixi users can also manually add  other XMPP addresses or like as a normal XMPP user you can add a Qixi user by knowing the  phone number and typing phone number at Qixi.i am I talking to that as if it were a regular  XMPP account which it is.  So to make it even easier for Qixi users you could also add your phone number and XMPP  address to the so-called Qixi directory and that will enable Qixi users to discover your  real XMPP address based on your phone number.  And so basically like the tagline is that conversations is for you and Qixi is for your  non-nerd friends.  And I've heard stories where people send the Qixi place the link to their grandmother  and like two minutes later they got contacted on XMPP because like discovery and sign up  is so easy.  So if you are thinking about giving Qixi to your non-nerd friends you probably want to  enter your phone number and your XMPP address into the Qixi directory and with that code  you can also do that for free.  Basically it's five bucks per entry and that's used to cross finance Qixi because like Qixi  is available for free also to make the onboarding easier and yeah.  So that's how we usually try to fund the server but yeah.  If you want to do it now you can do it for free with that code.  Another interesting set of clients are the clients that are formerly known as Tiger's  Messenger and that could have actually been interesting because it's a branding thing.  So if they would have kept the name across all platforms you could just theoretically  tell people just download Tiger's Messenger and then no matter what platform they are currently  on it would just work out.  However apparently it's what's like completely separate apps and then their customers were  very confused that even though it's all the Tiger's Messenger they're like different feature  sets and yeah apparently for the company that does that there's also a little incentive  to make them to gain feature parity between them because usually it's a server manufacturing  industry and to them Tiger's and the other clients is just a tech demo to show their  customers what XMPP is capable of and so they split it off and gave like each client for  each platform a different name.  So the clients for iOS and Mac OS, Syskin and Beagle are probably the most interesting  ones that are kind of feature complete that support HTTP upload and a Mimo and even Jingle  calls and on those platforms the competition isn't really good either so they are definitely  interesting to check out.  Yeah Xsabra that's a similar situation like that that is also one client that on papers  available on different platforms.  It used to be an Android client for a long time but they also have a web client and they  are also working on an iOS client which is currently in a closed beta and there's no  public source code yet.  So yeah that's another contender in the unified brand approach but to be honest it's a little  bit worrisome because apparently they don't like a lot of these extensions like they don't  like Macs, they don't like stream management and they always write on the XMP standards  mainly so they don't like the extensions and they have come up with something that is way  way better but it's only documented in Russian and yeah so I'm not sure what their future  plans are so they might actually develop that into something that's not actually compatible  with XMPP anymore but we'll see.  It's definitely worth like keeping an eye on.  So lessons learned that's not actually probably not actually lessons in that I don't have  a conclusion on that but more like observations I made.  For example there's a thing of Jingle file transfer versus HTTP upload.  So Jingle is a fairly complex protocol to negotiate peer-to-peer sessions.  It can be used to negotiate voice of IP sessions but also file transfer.  Actually everything that can be sent peer-to-peer.  It's very powerful but it's also very complex.  In a way it's a protocol within a protocol and people love it because in theory you can  use it to send large files between people and the server is not involved at all.  However due to its complexity it only has three finished implementations and every time  I did interrupt testing with one of the other implementations I discovered bugs in either  conversations or the other side.  On the other hand you have something like HTTP upload where files are not exchanged directly  but stored temporarily on the XMPP server and it gets the job done and anyone can implement  that in the afternoon.  On the other hand you have something like Omimo which is also like a fairly complicated  extensions as well but now it's actually widely implemented.  Some clients like the Windows universal platform thing I told you about even gave it a higher  priority to implement than some other more essential extensions.  However there isn't really good alternative available to Omimo and users really want to  use entrant encryption.  So even if that's not a really perfect extension it will still get implemented.  That already concludes my talk.  Are there any questions?  Yes, Isie.  Hello.  I can your repeat your question.  I guess.  Yeah.  Does the Qixi financing, your business model, does it actually work?  Or are you paying for Qixi?  Good question.  No, it doesn't really.  I mean, I came up with that elaborate business model because sending SMS is really expensive.  I was dreaming of a thousand registrations a day or a month or whatever, right?  And then I would run into very high costs to send those SMS.  So I was desperately looking for a business model because I couldn't pay for a thousand SMS a month myself.  But in reality, I only get like a hundred SMS a month or whatever, and I can easily pay for that myself.  And I cross-finance that with what I get from the conversations revenue on the Google Play Store or a few entries we do see on the directory.  But no, currently the entries in the directory are not paying for the server, but that's still fine because I'm making money off of conversations on the Play Store and I can just cross-finance that way.  And a second question is what if other developers would create a similar onboarding experience like Qixi and would you ask them to provide an own directory?  Or would you like to federate?  I mean, it may be confusing if every app has its own directory.  Yeah, good question as well.  So I mean, it depends a little bit on what they want.  If they wanted to do that, the source code for the Qixi directory is open source and they could just combine that with an eJab ad and just do their own thing.  But I could also imagine that, for example, if you see chat secure developer want to do Qixi for iOS and just use the same address space that they could just use my directory and my server.  It might be open for that.  I mean, it's a little bit challenging.  I wouldn't really want anyone to use it without telling me even though they could.  I mean, the API is even documented and everything.  But I'm a little bit afraid of running into the problems that I briefly mentioned with Tigers that you have two different apps, essentially, that are called the same, both called Qixi, but they are behaving very differently.  Not having a future priority or then someone joins the chat room.  I have a problem with Qixi.  I can't send files and you first have to ask back what platform are you using because they are behaving that differently.  But yeah, if someone would write a really good iOS client that would be on par with conversations, that would be totally open for them to just use the same domain.  Okay.  I guess no more questions.  Then thank you again.
2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_0_59.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_60_167.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_168_371.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_372_467.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_468_2579.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_2580_3959.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_3960_4643.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_4644_4691.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_4692_4775.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_4776_5099.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_5100_5183.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_5184_6431.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_6432_6599.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_6600_7355.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_7356_9647.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_9648_10451.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_10452_12611.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_12612_12779.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_12780_13703.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_13704_14267.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_14268_14711.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_14712_15227.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_15228_15983.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_15984_16247.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_16248_16391.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_16392_20303.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_20304_21803.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_21804_21887.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_21888_25691.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_25692_25775.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_25776_25943.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_25944_27239.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_27240_28019.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_28020_28499.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_28500_29951.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_29952_30155.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_30156_30251.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_30252_31115.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_31116_31895.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_31896_32759.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_32760_32927.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_32928_36275.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_36276_37679.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_37680_39191.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_39192_41231.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_41232_42695.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_42696_43739.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_43740_44147.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_44148_45803.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_45804_47627.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_47628_48455.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_48456_49295.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_49296_50207.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_50208_50759.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_50760_56435.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_56436_56483.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_56484_58055.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_58056_58343.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_58344_59939.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_59940_61007.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_61008_61307.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_61308_64787.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_64788_66287.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_66288_66767.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_66768_66899.png 2019_-_The_state_of_the_XMPP_Community_sKujNz-B6Ug_66900_67014.png
Oh, and it's time. Yeah, thank you all for coming, even though apparently there's a very popular talk going on at the same time. So, yeah, thank you for choosing this one over the other one. This is not going to be a technical talk. If you want more technical insights into XMPP, I'll refer you to talks I gave in the past. You can find most of them on media.cccde, for example, by searching for XMPP or searching for my name. Some of them are also linked from the FrostCon schedule. I think that's okay, right? Yeah, instead, I want to talk more generally about the XMPP community, the events we organize and essentially how we develop software. And after that, I want to dive very briefly into some commercial uses of XMPP because that are things that you might not know as a regular user. Yeah, then we will simply go over a bunch of clients that are currently in active development, showcase some of them. And last but not least, I want to share some observations I made while working on XMPP. So it's not directly a summary from my talk, but more general things that I noticed. I wasn't quite sure how to refer to the group of people that I want to talk about. In previous talks, I used Ctam-Jabbar to refer to the network of publicly federating servers as opposed to XMPP protocol that can be used in all sorts of contexts. But I don't like that word very much anymore, partially because Cisco owns the trademark on that word. And yeah, so I wasn't really sure what to call that. I mean, noncommercial would be another term, but that also isn't a really good fit either because there are some commercially operated providers that are still part of that network and there are also clients that you have to pay for. So just note when I say open source community, I'm basically referring to people like you and I that are using Cpublicly federating servers. So let's begin by asking ourselves who uses XMPP? Basically in a federated system, we have no way of knowing who uses XMPP and that's a good thing. Most providers make a point in not storing things like the IP address and generally store as little data as necessary. And even if some public servers would publish that information, we don't account for the countless of personal and small office servers that fly entirely under the radar. However, if we knew that XMPP, for example, was over or underrepresented in a certain country, for example, we could learn from that and repeat what we do in successful countries and less successful ones and attempt to grow the community that way. So what these download stats from conversations show is that they pretty much confirm what I observe myself when talking to users or in our chat room or when looking at the users on the GitHub issue tracker. Also I made the observation that when I tell someone at a conference here in Germany like Frostconn on the KLS Communication Congress that I'm working on XMPP, that they do know what I'm talking about. They might not use it, they might not even like it, but they still have heard of XMPP. However, last year I was at a conference in Singapore and during the occasion hallway discussions I mentioned that I'm working on XMPP and nobody had a clue what I was talking about. Similarly, when I'm at the Google Summ of Code Mentor Summit in the United States, which had a pretty international audience, I also feel like I have to explain what XMPP is. So yeah, those stats pretty much confirm that observation. However, you have to know that the data is kind of problematic anyway because roughly only 25% of users get conversations from the Play Store and the rest use FDroid. And even that 25% is problematic because it's just a guess. Now if you look at the download stats from conversations legacy which is available for free on the Google Play Store, we see something interesting. So out of nowhere we suddenly see Indonesia on that list. But the rest of the list remains roughly the same. We have Russia on this list, we have Spain in the United States, we all saw them on the other list as well. I actually don't have a good explanation for that. Obviously, two years is a lot more money in Indonesia and more importantly, people in Indonesia might not have credit cards. But it's not like the free version would see an equal distribution worldwide. It's skewed towards Germany and then we just got Indonesia additionally on that list. And also Xabar which is also available for free which is an alternative client reported similar stats on Twitter that they also see like in Germany, Russia and Indonesia as they are top three countries. When we look at the Quixi stats, it's even more obvious. And that's kind of a sense because I only ever mentioned Quixi during the initial presentation I gave in Berlin and then it was mentioned by a German online magazine and by an offline computer magazine also in Germany. So it's kind of makes sense that we see that Germany has a lot of users. However, it also gives us a guideline on what we have to do to spread it over the rest of the globe and that's basically like telling users about it. So this data is highly problematic as well. So people gather the data, use only one probably fairly biased list of servers and also they looked at the A record not as the SFV record. So they basically looked at where the website is hosted not where the XMPP servers hosted. But still if there is at least some truth to that data, it also confirms what we are seeing in the other statistics. And also like if a vast majority of XMPP users are from Germany, it's natural to assume that they use and operate servers in Germany. Interestingly the people who published that data try to spin it into an argument on how XMPP isn't really federated because all the servers are in the same place. However to me it's just obvious that users pick servers close to them. Looking at the developers of XMPP, it becomes harder and easier at the same time. There's no central instance that would collect that data. The XMPP standards foundation has a list of members but that doesn't keep track of where they are from. But that's also ignoring that some developers are not registered with the XMPP standards foundation anyway. So what I did instead was go over the list of XMPP software on the XMPP arc list and like manually looked into a guitar profile pages or contact information on websites and stuff like that to collect that list. And again you see a lot of Europe, Germany and France in particular stood out and again like Russia and the United States. So lately many events are organized in the XMPP community and first and foremost that's the XSF summit, the main event basically where the open source and the non-open source people come together and discuss upcoming extensions and long term plans for the future of XMPP. This year discussions included better message archiving like storing messages and metadata like read information or delivery information together. We also talked about mix which is in some future going to replace a Mac as the group chat for the call. That's always a very intense two days because there are like 50 expert in that field sitting around one conference table and having very like in-depth conversations about like the innards of XMPP. Community organized events, we try to avoid the term hackathon because that was hijacked by the industry to mean something else. But it's usually developers coming together usually over a week and to learn from each other to rapid prototype things that might require like both server and client implementation just to be social and meet basically the people they have previously only known online. Actually, you found early attempts of sets that date back to 2013 but for a year now if you've been doing them on a fairly regular basis. Usually everyone could organize one themselves and we try to help you or guide you to organize a sprint yourself. How to on our wiki and we also will give you visibility. There's a marketing team within the XSF and when you want to organize a sprint, we will help you like get the word out. But the vast majority of sprints this year or last year have been organized by one person. Thank you, Pep. You're not here. Thank you. But lately after like publishing the how to and stuff like basically everyone would have the power to do that themselves and if there are any questions, we will still help you or even like attend your sprint. Also that's like more informal. There are meetups. There are monthly meetings. It's just people coming together also users not just developers but also XMPP users. The Berlin meetup is going for several years now and there are times where just two people would show up but they kept it going and just continued doing it. And now there are like 10 to 20 people showing up. In Dresden where I'm currently living, we started one like three months ago and there we have like five to 10 people coming. The Berlin and Dresden ones are next week and the Munich one is the week after that. So if you're living in one of the cities, feel free to come there. Yeah. And also we are attending conferences. For example, the XSF themselves, they have a booth at FOSDEM because FOSDEM is right after the XMPP summit and that's kind of the most official one. You can get the official merch, you can buy an XMPP hoodie and get bottle openers and stickers. In recent history, we also attended the CCC events and we are going to attend camp in two weeks, I guess. However, those resemble more sprints and booths at normal conferences. However, you can still come by and talk to us or get stickers and stuff like that. And yeah, of course, we also have a booth here at Frostcon, which was actually very well visited today, but feel free to come by tomorrow if you haven't already today. Yeah. Let's look into some improvements that happen to the ecosystem itself. That's not like improvements to servers or clients, but to the general ecosystem that kind of improves the user experience for users wanting to use XMPP. So that's one of the coolest projects that have emerged in the last year. It will basically find you open conferences or open group chat to talk to other people and what it does, it crawls a vast number of servers and then generates a list of public rooms ordered by the number of participants so that you are finding the good ones first and it also allows you to search. Yeah, usually that's a website, but it also has an API so that you can integrate that into your client and so users of your client would automatically find someone to talk to with their new to XMPP, for example. Basically it's a centralized service that would either collect your IP address or could potentially collect your IP address or your Java ID depending on whether you are accessing the API over HTTP or XMPP, but yeah, I guess that's just what you have to live with. So there's no other way to solve that problem. And a nice little project is the Mac badge that if you want to link your XMPP group chat from your website or from your project's GitHub page, you can use that instead and it integrates nicely into the list of badges you might have anywhere and displays how many people are currently in that list and you can also link it automatically to that list so if people have an XMPP client installed they can click that badge and we'll get right into that group chat. Also while we are on the topic of badges, if you operate a public XMPP service there's another badge that you can stick on your website and that uses information generated by status.conversations.im and that's basically like a monitoring tool that will check if your XMPP server is online and available but it needs credentials to log in so you would have to go to status.conversations.im and enter credentials like test credentials obviously for your server and then like so that later you could stick that badge on your website if you want to. So one of the arguments you hear often against XMPPs is that there are too many extensions and as an implementer you don't know what to implement and as a user you don't know what client to download and there's certainly some truth to that. We currently have more than 400 extensions so to counteract that for a while we had so-called compliance suite which are basically meant for developers to tell them implement those 10 extensions and everything will be fine and there are different profiles for example the web client might need to implement a slightly different set of extensions or then let's say mobile client. And recently we made some efforts to also expose that information to end users. A client that is compliant to a certain profile can show a badge to their users and then users can specifically look for compliant clients sort of a seal of approval. Ideally it would also act as an incentive for developers to implement the compliance profiles. Currently there's a design competition going on on how that seal of approval might look like and so as a client developer you even know if you implemented one of the compliance suites and just show the badge. There could also possibly be self-assessment tests in the future where you basically check off every extension that you've implemented and it will tell you what profile you implemented and there's a prototype for that on Bitbucket. Or even better you could put all the extensions you implemented in a special XML file together with some additional information about your project and then the xmpp.org website that lists different clients could automatically determine that based off the XML file. But if you make the information machine readable you can also do the reverse. So when viewing XSAP you could also see what software implements that specific extension. So actually the vast majority of servers these days is compliant. So it's usually just a case of whether or not your service up to date and configured correctly and so there's the compliance tester. There's not meant to check out server software but more check out if you as a provider have configured everything correctly and it also has like email notifications and direct access to help if you're missing something. So if you're checking your own server and it detects that something is missing to be fully compliant it will automatically tell you oh you need to change that in your configuration file to fix the issue or update your server or whatever. So recently there have also been some attempts to unify the UX across different clients. That doesn't mean having the same UI on every client but at least some common vocabulary for example. For example what to call a group chat or even what to call the JAB ID or should we call it XMPP address. So yeah there was one sprint recently where specifically only like tried to develop that common vocabulary and tried to discuss how we can make the clients more uniform. Also there's a neat little extension called consistent color generation. What it does is basically that if one user has a red avatar like an automatically generated avatar on one client it will also have the same shade of red on the other client. So that will be easier to recognize the user across different clients. If my friend Peter is green on one client he will also be green on the other client. So on the topic of growing the communities that's twofold on one hand we obviously want to attract more users but we also desperately need more developers. A vast majority of developers only work part time on XMPP and that in turn means to compensate for that we need to attract more developers. Growing the user base is simple but not easy. Basically what we do is we need to spread the word for example that graph is the quick seed download on the Play Store after it received publicity on a German computer magazine and this also ties back to the beginning of the talk. And basically the reason I believe that kind of says it's significantly more successful in Germany is that we get some news coverage here in Germany while we get no news coverage in other countries. Yeah, and like I said we also recognize that we need more developers. Proper companies have dedicated people for that so called developer advocates that go to every conference in the world and tell everyone how great their tooling is. And yeah, it's also a great documentation to make it easier for people and we all have to do that ourselves. However, we identified the need for it and we're trying to set aside some time to do all that. Talking about commercial usage of XMPP is always a bit challenging because people are often oddly secretive about things and when I'm working on commercial projects I'm usually under NDA most of the time. So for me it's actually easier to talk about other people's projects. However, I still want to give you some examples. One funny example I learned about recently that a fashion label was using is it because apparently when you buy expensive fashion these days you're not going into a store or like an even an online store but you buy it on Instagram or Snapchat and then they were using XMPP to find all that communication from the different channels into their back end. Yeah, also NATO and a lot of government agencies are using XMPP. Usually they use special clients from companies that specifically cater to that market and then those clients have special features like marking messages top secret or only for Germany and then they have basically XMPP firewalls sitting in between for example the UK Army and the German Army that filters out messages based on that criteria. But I also know at least one intelligence agency that uses vanilla conversations with vanilla eJabadi. So yeah, but you might ask yourself why what do we have, I mean what's in fast if NATO uses XMPP right, they're using their own clients so what's in fast and it's a lot of implementation experience so like on the XSF summit roughly half of them are working like in those closed source projects and when they implement MIX for example which again is the successor to mark for group chat they might not able to share the implementation but they are definitely able to share the experience and then we can learn from that. And also a lot of the big servers are backed by companies who make money with those type of customers and that's why a lot of the servers actually relatively up to date with all the extensions. So yeah, let's talk about clients. So there's Converse.js and that's not just the best web client you can get but also one of the best clients overall. It's fairly actively developed. It has had two major releases over the last 12 months and counters of mine and bug fix releases. Last year the developer actually worked full time on that and now here's a job where he's allowed to work on Converse and yeah, last year it received a support for HTTP upload and the latest version which was actually released this week got support for stream management which means you can switch over from Bosch to WebSockets which should be way more efficient. Moving also interesting because it's one of the few web clients and it's actually more of a social network with chat capabilities. And yeah, I'm mentioning it here because A it's like doing a little bit, things a little bit different, it's more of a social network and that shows you that you can also use XMPP to develop that but it was also the first client that implemented emoji reactions which are basically like sums up to a message for example and that's like also the new hotness in the XMPP community and stuff that other clients are currently working on as well. It does require PHP backend for proxying and caching things so it doesn't talk to you XMPP server directly so if you want to set it up it's a little bit more complicated to do than for example just running Converse which is just JavaScript that you can deliver on a website. Yeah, so Dino uses GTK on paper platform independent, got Domemo on HTTP upload about a year ago also has support for PGP which is interesting because it's one of the newer clients that like deliberately implemented PGP even though that's a fairly old extensions. Progress is slow but steady. Google sum of code student is currently working on Jingle file transfer which you would need if you want to transmit really large files that are not covered by HTTP upload because usually on HTTP upload there's a file size limit and yeah. Then Dino if you're trying to transmit a file that is larger than what HTTP upload allows it will automatically fall back to basically peer-to-peer file transfer which is the same that conversations is doing as well. Yeah it's my personal daily driver however there's no official release yet which is like super annoying because like people on macOS and Windows have to compile it themselves. But it still has a very clean UI and also basic features so people still flock to it even though it doesn't have an official release. So there's Gatium that's basically the polar opposite to Dino, it has all the XMPP features like all of them and in parts the UI is a little bit cluttered and the code base is the mess. It's a pretty old client, the current maintainer I think is the third maintainer of that client. However the maintainer is actively working on cleaning it up and cleaning up both the code base and the UI and he's also very involved in the community and interesting in supporting new things. For example the current master branch has support for the Mac search that I mentioned earlier and he's also like I said trying to clean up the UI and become a little bit more like Dino in that way but I'm afraid it might be difficult to shake off the preconception of cluttered UI even if it will improve in the future. So yeah let's see how that will go. So Poetio that's basically the Gatium of text UI's, it has plugins for almost everything except unfortunately Omimo but it is in the works right here but it has plugins for HTTP upload, emoji reactions and yeah everything. There's one for code like highlighting and rendering avatars even though it's technically a console client and yeah it's kind of the prosody of clients, it's pretty easy to prototype it because it's written in Python and everyone knows at least a little bit of Python. Yeah then there's profanity which is also like a console client, noteworthy because it got Omimo support just recently and it also has support for HTTP upload. So yeah there's UWPX, interesting because usually Windows support for XPB clients is always a second class citizen because most XPB developers are Linux or whatever and so that's interesting because that's a dedicated Windows client and it uses the universal Windows platform toolkit which allows you to write the same software for different platforms so it will run on your Windows and on your Xbox for example and technically it would also run on Windows phones which would be super cool if Microsoft wouldn't have stopped making those. Yeah it's also interesting because it has some basic support for Omimo but virtually nothing else so they prioritized Omimo over HTTP upload and stream management and MAM and everything and it's still very alpha but yeah interesting because of all the other reasons. So this Kydem which also has an interesting concept because it uses QT and the KDE Kirigami library to be truly platform independent. So on paper it would work on your Android phone, on your MacOS, on KDE. However it doesn't really feel native on Android. For example the file slash image picker uses a built in file browser that can only access files within the Kydem space so you can share the database of Kydem but nothing else because you don't have permissions to access anything else. It also doesn't stay connected in the background on Android. I'm not sure if they're able to fix it or yeah but it supports things like HTTP upload as you can see in the screenshot obviously but it doesn't have support for group chats just yet and no support for Omimo however both of them are planned for the next two milestones. Chat secure yeah not much happened in the last year of Chat secure. A couple of maintenance releases where they bumped the versions of libraries. He's currently working on porting it to MacOS. This is a project catalyst thing which allows you to port an iOS app to MacOS and he's currently working on that. However it's still probably one of the best options if you're using iOS and it supports HTTP upload and Omimo. So there's Monal another iOS client that has actually been around for a while but wasn't very active for quite some time. However the development pace has increased lately and it also has support for Omimo and it doesn't have support for group chat though. But since all clients on iOS are less than ideal so yeah I mentioned all of that so you can pick and choose. So obviously there's conversations and for the most part of 2019 it was focused on stability rather than chasing new features and I only did a few things like incorporating the changes from the UX sprint where I made it to use the common vocabulary that we came up with and it also gained support for the Mac search and backups is also a feature that it got this year. Yeah, however I do have a roadmap towards conversations 3.0 and note that it's definitely not a timeline just the plans that I have for the future. However I have secured funding for voice over IP basically jingle audio and video calls and that's going to be the next thing I'll be working on. Yeah, there's Qixi. That's basically a spin off of conversations not a fork but something that's developed in the same source tree and that's basically conversations but you can on-bottom your phone number and it would automatically find other Qixi users based on their phone number. And you can also chat with regular XMPP users on that and Qixi users can also manually add other XMPP addresses or like as a normal XMPP user you can add a Qixi user by knowing the phone number and typing phone number at Qixi.i am I talking to that as if it were a regular XMPP account which it is. So to make it even easier for Qixi users you could also add your phone number and XMPP address to the so-called Qixi directory and that will enable Qixi users to discover your real XMPP address based on your phone number. And so basically like the tagline is that conversations is for you and Qixi is for your non-nerd friends. And I've heard stories where people send the Qixi place the link to their grandmother and like two minutes later they got contacted on XMPP because like discovery and sign up is so easy. So if you are thinking about giving Qixi to your non-nerd friends you probably want to enter your phone number and your XMPP address into the Qixi directory and with that code you can also do that for free. Basically it's five bucks per entry and that's used to cross finance Qixi because like Qixi is available for free also to make the onboarding easier and yeah. So that's how we usually try to fund the server but yeah. If you want to do it now you can do it for free with that code. Another interesting set of clients are the clients that are formerly known as Tiger's Messenger and that could have actually been interesting because it's a branding thing. So if they would have kept the name across all platforms you could just theoretically tell people just download Tiger's Messenger and then no matter what platform they are currently on it would just work out. However apparently it's what's like completely separate apps and then their customers were very confused that even though it's all the Tiger's Messenger they're like different feature sets and yeah apparently for the company that does that there's also a little incentive to make them to gain feature parity between them because usually it's a server manufacturing industry and to them Tiger's and the other clients is just a tech demo to show their customers what XMPP is capable of and so they split it off and gave like each client for each platform a different name. So the clients for iOS and Mac OS, Syskin and Beagle are probably the most interesting ones that are kind of feature complete that support HTTP upload and a Mimo and even Jingle calls and on those platforms the competition isn't really good either so they are definitely interesting to check out. Yeah Xsabra that's a similar situation like that that is also one client that on papers available on different platforms. It used to be an Android client for a long time but they also have a web client and they are also working on an iOS client which is currently in a closed beta and there's no public source code yet. So yeah that's another contender in the unified brand approach but to be honest it's a little bit worrisome because apparently they don't like a lot of these extensions like they don't like Macs, they don't like stream management and they always write on the XMP standards mainly so they don't like the extensions and they have come up with something that is way way better but it's only documented in Russian and yeah so I'm not sure what their future plans are so they might actually develop that into something that's not actually compatible with XMPP anymore but we'll see. It's definitely worth like keeping an eye on. So lessons learned that's not actually probably not actually lessons in that I don't have a conclusion on that but more like observations I made. For example there's a thing of Jingle file transfer versus HTTP upload. So Jingle is a fairly complex protocol to negotiate peer-to-peer sessions. It can be used to negotiate voice of IP sessions but also file transfer. Actually everything that can be sent peer-to-peer. It's very powerful but it's also very complex. In a way it's a protocol within a protocol and people love it because in theory you can use it to send large files between people and the server is not involved at all. However due to its complexity it only has three finished implementations and every time I did interrupt testing with one of the other implementations I discovered bugs in either conversations or the other side. On the other hand you have something like HTTP upload where files are not exchanged directly but stored temporarily on the XMPP server and it gets the job done and anyone can implement that in the afternoon. On the other hand you have something like Omimo which is also like a fairly complicated extensions as well but now it's actually widely implemented. Some clients like the Windows universal platform thing I told you about even gave it a higher priority to implement than some other more essential extensions. However there isn't really good alternative available to Omimo and users really want to use entrant encryption. So even if that's not a really perfect extension it will still get implemented. That already concludes my talk. Are there any questions? Yes, Isie. Hello. I can your repeat your question. I guess. Yeah. Does the Qixi financing, your business model, does it actually work? Or are you paying for Qixi? Good question. No, it doesn't really. I mean, I came up with that elaborate business model because sending SMS is really expensive. I was dreaming of a thousand registrations a day or a month or whatever, right? And then I would run into very high costs to send those SMS. So I was desperately looking for a business model because I couldn't pay for a thousand SMS a month myself. But in reality, I only get like a hundred SMS a month or whatever, and I can easily pay for that myself. And I cross-finance that with what I get from the conversations revenue on the Google Play Store or a few entries we do see on the directory. But no, currently the entries in the directory are not paying for the server, but that's still fine because I'm making money off of conversations on the Play Store and I can just cross-finance that way. And a second question is what if other developers would create a similar onboarding experience like Qixi and would you ask them to provide an own directory? Or would you like to federate? I mean, it may be confusing if every app has its own directory. Yeah, good question as well. So I mean, it depends a little bit on what they want. If they wanted to do that, the source code for the Qixi directory is open source and they could just combine that with an eJab ad and just do their own thing. But I could also imagine that, for example, if you see chat secure developer want to do Qixi for iOS and just use the same address space that they could just use my directory and my server. It might be open for that. I mean, it's a little bit challenging. I wouldn't really want anyone to use it without telling me even though they could. I mean, the API is even documented and everything. But I'm a little bit afraid of running into the problems that I briefly mentioned with Tigers that you have two different apps, essentially, that are called the same, both called Qixi, but they are behaving very differently. Not having a future priority or then someone joins the chat room. I have a problem with Qixi. I can't send files and you first have to ask back what platform are you using because they are behaving that differently. But yeah, if someone would write a really good iOS client that would be on par with conversations, that would be totally open for them to just use the same domain. Okay. I guess no more questions. Then thank you again.
one. This is not going to be a technical talk. If that you might not know as a regular user. Yeah, previous talks, I used Ctam-Jabbar to refer to to explain what XMPP is. So yeah, those stats good explanation for that. Obviously, two years countries. When we look at the Quixi stats, it's guideline on what we have to do to spread it over if a vast majority of XMPP users are from into an argument on how XMPP isn't really the open source and the non-open source people for a year now if you've been doing them on a on our wiki and we also will give you visibility. of improves the user experience for users wanting projects that have emerged in the last year. It that there are too many extensions and as an And recently we made some efforts to also expose compliance suites and just show the badge. There extension that you've implemented and it will in a special XML file together with some unify the UX across different clients. That is green on one client he will also be green on desperately need more developers. A vast majority trying to set aside some time to do all that. developed. It has had two major releases over the hotness in the XMPP community and stuff that those. Yeah it's also interesting because it has Chat secure. A couple of maintenance releases that. However it's still probably one of the best rather than chasing new features and I only did a vocabulary that we came up with and it also also a feature that it got this year. Yeah, only documented in Russian and yeah so I'm not implementations and every time I did interrupt