We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

The state of the XMPP Community

00:00

Formal Metadata

Title
The state of the XMPP Community
Title of Series
Number of Parts
94
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
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.
15
Thumbnail
1:16:56
20
Thumbnail
59:24
23
Thumbnail
10:02
48
Thumbnail
50:08
56
76
Thumbnail
12:05
Electric currentFreewareOpen sourceOpen setClient (computing)Table (information)Multiplication signScheduling (computing)State observerSoftwareGroup actionEvent horizonTerm (mathematics)Client (computing)HypermediaCartesian closed categoryRegular graphRight angleSoftware developerXMLUMLLecture/ConferenceComputer animation
WordSoftwareOpen sourceService (economics)Context awarenessFitness functionQuicksortClient (computing)Internet service providerMereologyServer (computing)Communications protocolLecture/Conference
Internet service providerServer (computing)IP addressService (economics)Point (geometry)Physical systemInformationStatistics1 (number)Data conversionLecture/Conference
StatisticsGoogolTelecommunicationCodeType theoryState observerData conversion
StatisticsData conversionData storage deviceState observerLecture/Conference
StatisticsData conversionElectronic mailing listStatisticsArmSimilarity (geometry)PlastikkarteTwitterPresentation of a groupGleichverteilungClient (computing)NeuroinformatikRevision control
Server (computing)Open sourceInformationSoftwareSequelServer (computing)Electronic mailing listRow (database)Instance (computer science)Software developerSoftwareProfil (magazine)TrailMultiplication signService (economics)InformationParameter (computer programming)WebsiteStatisticsWeb pageArc (geometry)Lecture/Conference
Event horizonElectronic mailing listWebsiteInformationEvent horizonExtension (kinesiology)Open sourcePlanningMessage passing
Message passingOnline chatInformationMixed realitySystem callMetadataTable (information)Expert systemField (computer science)Event horizonLecture/Conference
WikiRapid PrototypingEvent horizonSoftware developerTerm (mathematics)Arithmetic meanSet (mathematics)Client (computing)ImplementationBasis <Mathematik>Server (computing)1 (number)
WikiWikiElectronic program guideWordSoftware developer1 (number)Power (physics)Multiplication signPauli exclusion principleLattice (order)Lecture/ConferenceComputer animation
Chaos (cosmogony)TelecommunicationOpen setNormal (geometry)Projective planeService (economics)Client (computing)Event horizon
Online chatProjective planeNumberGroup actionOnline chatOpen setServer (computing)Electronic mailing listIP address1 (number)Process (computing)Client (computing)Service (economics)
HyperlinkOnline chatCore dumpClient (computing)Server (computing)Suite (music)Mobile WebProjective planeExtension (kinesiology)InformationWebsiteSoftware developerServer (computing)Group actionProfil (magazine)Electronic mailing listElectronic visual displayClient (computing)QuicksortSoftware testingSet (mathematics)Parameter (computer programming)Different (Kate Ryan album)Web browserData conversionWeb pageArmLink (knot theory)ImplementationInstallation artService (economics)Suite (music)Lecture/Conference
Computer fileBlogSuite (music)Linear programmingSoftware developerStapeldateiCompilation albumClient (computing)Suite (music)WebsiteServer (computing)Internet service providerSoftwareInformationExtension (kinesiology)PrototypeEmailSoftware testingReverse engineeringComputer fileVirtual machineProfil (magazine)Configuration spaceService (economics)Projective planeLecture/Conference
ConsistencyComputer fileServer (computing)Configuration spaceClient (computing)Different (Kate Ryan album)Avatar (2009 film)ConsistencyExtension (kinesiology)Address spaceGroup actionElectric generatorGraph coloringProcess (computing)Lecture/ConferenceXML
Client (computing)Different (Kate Ryan album)Software developerLecture/ConferenceComputer animation
Software developerGoogolCodeSuite (music)Graph (mathematics)WordSoftware developerData conversionMultiplication signData storage deviceNeuroinformatikBitProper mapComputer animation
Server (computing)Heat transferClient (computing)Multiplication signProjective planeData conversionFirewall (computing)Client (computing)Server (computing)Type theoryOpen sourceGroup actionTelecommunicationMessage passingData storage deviceExtension (kinesiology)ImplementationRight angleWeb 2.0Mixed realityFilter <Stochastik>Lecture/Conference
Computing platformData conversionLimit (category theory)Extension (kinesiology)Student's t-testProcess (computing)Arithmetic progressionSoftware bugComputer fileRevision controlWeb browserStreaming mediaBitPerturbation theorySummierbarkeitFront and back endsClient (computing)Software developerServer (computing)Different (Kate Ryan album)Data miningMessage passingHeat transferOnline chatData managementGoogolCodeProgram flowchart
Peer-to-peerLimit (category theory)Data conversionHeat transferDevice driverComputer fileFlock (web browser)Inheritance (object-oriented programming)WindowLecture/Conference
Duality (mathematics)Client (computing)WindowAvatar (2009 film)Insertion lossPlug-in (computing)Video game consolePrototypeBitMereologyBranch (computer science)Software maintenanceMachine codeMaxima and minimaSoftware developerUniverse (mathematics)Computing platformWeb browserOcean currentUser interfaceSource code
Computing platformStreaming mediaWindowData managementDifferent (Kate Ryan album)SoftwareLibrary (computing)Program flowchart
Computer fileLibrary (computing)Android (robot)SpacetimeDatabaseMedical imagingComputing platformGroup actionWeb browser
Message passingComputer-generated imageryFile viewerCodeDirectory serviceAndroid (robot)Address spaceNumberoutputVideoconferencingMobile appPlanningComputing platformSet (mathematics)Directory serviceFreewareDifferent (Kate Ryan album)Data conversionRevision controlSystem callSoftware maintenanceInformation securitySource codeRegular graphLibrary (computing)Normal (geometry)Parity (mathematics)Projective planeSoftware developerMultiplication signGroup actionReal numberClient (computing)MereologyStability theoryLink (knot theory)MathematicsOnline chatBackupMaxima and minimaCapillary actionGreatest elementDisk read-and-write headMachine codeMessage passingServer (computing)InternettelefonieLevel (video gaming)Line (geometry)
Android (robot)Client (computing)Computing platformServer (computing)outputComplete metric spaceDemo (music)
Online chatHeat transferComputer fileAlpha (investment)TwitterWebsiteClient (computing)Heat transferWindowComputer fileServer (computing)Communications protocolComputing platformImplementationUniverse (mathematics)Beta functionEncryptionExtension (kinesiology)Multiplication signExterior algebraData managementStreaming mediaWeb browserInterrupt <Informatik>outputElectronic mailing listSoftware testingStandard deviationState observerPlanningData conversionSoftware bugOvalSource codeProcess (computing)Complex (psychology)Different (Kate Ryan album)CuboidData storage deviceInternettelefonieBit rateComputer animation
WebsiteSoftware developerDirectory serviceComputer virusBitData storage deviceGoodness of fitImage registrationMobile appSimilarity (geometry)Source codeData conversionRight angleOpen sourceBusiness modelSoftware testingSingle-precision floating-point format
Server (computing)outputDirectory serviceMobile appComputing platformComputer fileBitClient (computing)Data conversionDomain nameAddress spaceSoftware developerGoodness of fitDifferent (Kate Ryan album)Lecture/Conference
Open sourceFreewareCartesian closed categoryXMLComputer animation
Transcript: English(auto-generated)
Oh, and it's time. Yes, thank you all for coming, even though apparently there's a very popular talk going on at the same time, so 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 will 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? Instead I want to talk more generally about the XMPP community, the events we organise and essentially how we develop software, and after that I want to dive very briefly
into some commercial users of XMPP, because there are things that you might not know as a regular user, yes, 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, 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 the term Jabber to refer to the network of publicly federating
servers as opposed to XMPP, the protocol that can be used in all sorts of contexts. I don't like that word very much any more, partially because Cisco owns the trademark
on that word, and yes, so I wasn't really sure what to call that, I mean non-commercial 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 the publicly federating servers. So let's begin by asking ourselves who uses XMPP? Obviously 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 service 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 the 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 FrostCon or 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 Summer of Code Mentor Summit in the United States which has a pretty international audience, I also feel like I have to explain what
XMPP is. So yeah, those stats pretty much like confirm that observation, however you have to know that the data is kind of problematic anyway because roughly only 25 per cent of users
get conversations from the Play Store and the rest use F-Droid, and even that 25 per cent 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, while 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 euros 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 like an equal distribution worldwide. It's still skewed towards Germany and then we just got Indonesia additionally on that
list. And also Xsaba which is also available for free which is an alternative client reported similar stats on Twitter that they also see like Germany, Russia and Indonesia as top three countries.
When we look at the Quixie stats, it's even more obvious. And that kind of makes sense because I only ever mentioned Quixie during the initial presentation I gave in Berlin and then it was mentioned by a German online magazine and then by an offline computer magazine also in Germany.
So it kind of makes sense that we see that Germany is like, has a lot of the 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 the people who gathered that data used only one probably fairly biased list of servers and also they looked at the A record, not the SFV record, so they
basically looked at where the website is hosted, not where the XMPP server is 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 tried 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 and 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 manually looked into a GitHub 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 organised in the XMPP community and first and foremost that's the XSF Summit, that's 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 and we
also talked about mix which is in some future going to replace a mark as a group chat for a call. That's always a very intense two days because there are like 50 experts in that field sitting around one conference table and having very like in-depth conversations about like the innards of XMPP.
Yes, and there are also more like community-organised 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 wrap a prototype, things that might require like both server and the client implementation, and just to be social and meet basically the people they have previously only known online.
Actually found early terms of that date back to 2013. But for a year now, we've been doing them on a fairly regular basis. Usually, everyone could organise ones themselves, and we try to help you or guide you to organise a sprint yourself.
We have like a 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 organise a sprint, we will help you like get the word out. But the vast majority of the sprints this year or last year have been
organised by one person. Thank you, Pep, you're not here, but thank you. Yes, 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 would still help you, or even like attend your sprint.
Also, that's like more informal, there are meet-ups, there are monthly meetings, and it's just people coming together, also users, not just developers but also XMPP users. The Berlin meet-up we see long is going, it's already 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 nowadays 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 the Dresden ones are actually next week, and the Munich one is the week after that, so if you're living in one of those 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. They can get like the official merch, you could buy like an XMPP hoodie and get bottle openers and stickers, and yeah. In recent history, we also attended 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 could 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 like 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 chats 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 it's at the 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 if they are new to XMPP, for example. Obviously, it's a centralised service that would either collect your IP address or could potentially collect your IP address
or your job 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 mock badge
that if you want to link your XMPP group chats 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 will 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 30 days later you could stick that badge on your website if you want to. Yeah, so one of the arguments you hear often against XMPP 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 suites, 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, a web client might need to implement a slightly different set of extensions than, let's say, a mobile client, and recently we made some efforts to also expose that information to end users.
The client that is compliant to a certain profile can show a badge to the users, and then users can specifically look for compliant clients, sort of a seal of approval. Ideally, that would also act as an incentive for developers to implement the compliancy 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 either know if you implemented one of the compliance suites and just show the badge, or there could also possibly be self-assessment tests
in the future where you basically check off every extensions 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 Xzap, 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 server's 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 email notifications
and direct access to help 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 this and 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 in 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 we specifically only 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 colour generation. What it does is basically that if one user has a red avatar, like a red automatically generated avatar on one client, it will also have the same shade of red on the other client, so that it will be easier to recognise the user across different clients.
If my friend Peter is green on one client, he will also be green on the other client. Yeah, 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.
Essentially, what we do is we need to spread the word, for example. That graph is the quick download from the Play Store after it received publicity on a German computer magazine. This also ties back to the beginning of the talk.
Basically, the reason I believe that conversations are 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 recognise 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 they also write documentation to make it easier for people. We all have to do that ourselves.
However, we identified the need for it, and we are 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 project. However, I still want to give you some examples. One funny example I learned about recently that a fashion label was using it because apparently when you buy expensive fashions these days,
you are not going into a store or 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 armies that then filters out messages based on that criteria. But I also know at least of one intelligence agency that uses Vanilla Conversations with Vanilla EJBD.
So yeah, but you might ask yourself, why, what do we have? I mean, what's in for us if NATO uses XMPP, right? They're using their own clients, so what's in for us? And it's a lot of implementation experience, so like on the XSF summit, roughly half of them are working 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 are 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 countless of minor bug fix releases. Last year the developer actually worked full-time on that,
and now he has a job where he's allowed to work on Converse. And last year it received Omero support, 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 things a little bit different, it's more of a social network 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 some stuff that other clients are currently working on as well. It does require a PHP backend for proxying and caching things that doesn't talk to your 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 with JavaScript that you can deliver on a website. Yeah, so Dyno uses GTK on paper as platform independent, got Dormimo and HTTP upload about a year ago, also has support for PGP, which is interesting
because it's one of the newer clients that 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 wanted to transmit really large files that are not covered by HTTP upload, because usually on HTTP uploads there's a file size limit. And yeah, then Dyno, 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 super annoying because people on Mac OS and Windows have to compile it themselves. Yeah, but it still has a very clean UI
and also all the basic features, so people still flock to it, even though it doesn't have an official release. So there's Gertram. That's basically the polar opposite to Dyno. 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 a mess. It's a pretty old client, the current maintainer. I think it's the third maintainer of that client. However, the maintainer is actively working on cleaning up both the code base and the UI, and he's also very involved in the community and interested in supporting new things.
For example, the current master branch has support for the Mac search that I mentioned earlier. And he's also, yeah, like I said, trying to clean up the UI and become a little bit more like Dyno 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 gadget of text UIs. It has plugins for almost everything, except unfortunately Oumimo, but it is in the works, I hear,
but it has plugins for HTTP upload, but Emoji reactions and yeah, everything. Yeah, 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 of clients. Noteworthy because it got Oumimo support just very recently,
and it also has support for HTTP upload. So yeah, there's UWPX. Interesting because usually Windows support for HTTP clients is always the second-class citizens because most HTTP developers are on 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 Oumimo, but virtually nothing else.
So they prioritise Oumimo 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 just Kaiden, 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 Mac OS, 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 Kaiden space. So you could share the database of Kaiden, 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 Oumimo.
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 bombed the versions of libraries. He is currently working on porting it to Mac OS.
So it's a project catalyst thing which allows you to port an iOS app to Mac OS 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 Oumimo. 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 Oumimo. And it doesn't have support for group chats, though.
But since the, yeah, all clients on iOS are less than ideal, so yeah, I'm mentioning all of that so you can like, I don't know, pick and choose. Yeah, 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 like made it use the common vocabularies that we came up with and it also gained support for the max 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 Quixie. That's basically a spinoff of conversations, not a fork but something that's developed
in the same source tree. And that's basically conversations but you can onboard with your phone number and it would automatically find other Quixie users based on their phone number. And you can also chat with regular XMPP users on that and Quixie users can also manually
add other XMPP addresses. Or like as a normal XMPP user, you can add a Quixie user by knowing their phone number and typing phone number at Quixie.im and talking to that as if it were a regular XMPP account, which it is. So to make it even easier for Quixie users,
you could also add your phone number and XMPP address to the so-called Quixie directory and that will enable Quixie 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 Quixie is for your non nerd friends and yeah, I've heard stories where people send the Quixie 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 yeah, if you are thinking about giving Quixie to your non nerd friends, you probably want to enter your phone number and your XMPP address into the Quixie directory and with that code, you can also do that for free. Usually it's five bucks per entry and that's used to like cross finance Quixie
because like Quixie 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. Yeah, another interesting set of clients
are the clients that were 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 platforms they're currently on, it would just work out, right? However, apparently it's what's like completely separate apps and then the customers were very confused that even though it's all the Tiger's Messengers that are 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 manufacturer and to them, Tiger's and the other clients,
it's just a tech demo to show the customers what XMPP is capable of and so they split it off and gave each client for each platform a different name. So the clients for iOS and MacOS, Syskin and Beagle are probably the most interesting
because they are kind of feature complete, they support HTTP upload and 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, Xabra, that's a similar situation like that.
That is also one client that on paper is 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 say, they don't like mocks, they don't like stream management and they always write on the XMPP standards main list so they don't like the extension
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 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 yeah, 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 voids of IP sessions but also file transfer. Basically 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's 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
and yeah, 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 it in the afternoon. Yeah, on the other hand, you have something like Omeo
which is also like a fairly complicated extensions as well but nowadays, 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 a good alternative available to Omeo and end users really want to use end-to-end encryption. So yeah, even if that's not a really perfect extension, it will still get implemented.
Okay, that already concludes my talk. Are there any questions? Test, is this on?
Test, test, hello, hello. I can repeat your question, I guess.
Yeah, does Quixie financing your business model, does it actually work or are you paying for Quixie? Good question, no it doesn't really. I mean, I came up with that elaborate business model
because sending SMS is really expensive. And I was like 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, right, so I was desperately looking for a business model because I couldn't pay for a thousand SMS a month myself, right.
But in reality, I only get like 100 SMS a month or whatever and I can easily pay for that myself and kind of cross-finance that with what I get from the conversations revenue on the Google Play Store or the 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, I mean I'm making money off of conversations on the Play Store and I can just cross-finance it that way. And a second question is what if other developers would create a similar onboarding experience like Quixie
and would you ask them to provide an own directory or would you like to federate or, 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 Quixie directory is open source and they could just combine that with an each other and just do their own thing. But I could also imagine that, like for example, if the chat secure developer wanted to do Quixie for iOS
and just use the same address space, that they would just use my directory and my server, 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 Tyga is that you have two different apps essentially that are called the same, that are both called Quixie, but they are behaving very differently. So not having a feature priority or then someone joins the chat room and I have a problem with Quixie, I can't send files,
then you first have to ask back what platform are you using because they are behaving that differently. But yeah, I mean 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.