Daniel Gultsch

Self-hosting UnifiedPush with Conversations as Distributor

Tue, 10 Mar 2026 00:00:00 +0000

You might have heard that XMPP in general, and Conversations in particular, make a great UnifiedPush Distributor. That is correct! However, you might find yourself in a dilemma: you already have an XMPP account with a trusted provider that you want to keep using, and you don’t want to host and maintain your own XMPP server. Furthermore, you may not feel comfortable using the publicly accessible Rewrite Proxy up.conversations.im. Luckily, you can easily self-host just the Rewrite Proxy component (the part that would otherwise default to up.conversations.im in Conversations).

Sending Jabber/XMPP Messages via HTTP

Mon, 09 Mar 2026 00:00:00 +0000

The goal of this tutorial is to set up a simple REST API that allows you to send XMPP messages to an existing XMPP account. This can be easily integrated into monitoring solutions or other scripts that send out status information.

While there are command-line tools like go-sendxmpp that send messages by connecting to an XMPP server directly, this guide is specifically about providing an HTTP interface.

curl "https://ntfy.stdmsg.tech:5281/msg/user@example.com" \
  -u coffee@ntfy.stdmsg.tech:secret \
  -H "Content-Type: text/plain" \
  -d "Your flat white is done"

Hint: If you don’t have an XMPP account to receive these messages, you can create one on a public server from within Conversations (F-Droid, Google Play) or another XMPP client of your choosing.

Multiple Vulnerabilities found in Dino

Thu, 12 Sep 2019 00:00:00 +0000

CVE-2019-16235+: Missing or incorrect sender validations in Dino allow an attacker to spoof messages and inject or remove entries from the user’s roster.

Introduction

Dino is a Jabber/XMPP client written in Vala and GTK. On September 10th 2019, while chatting on a public channel, a number of vulnerabilities were discovered in Dino. The discovery was initially prompted by a user of the name balu_der_bär who was deliberately sending fake Message Carbons to the channel. This quickly led to the diagnosis that Dino was not properly verifying the sender of a Message Carbon before parsing it (CVE-2019-16235). Message Carbons are only valid if they are coming from the user’s account. This vulnerability is an exact replica of the vulnerabilities already described in CVE-2017-5589+ that were discovered in February 2017 in multiple Jabber/XMPP clients.

A pathway to a well regulated instant messaging market

Wed, 08 May 2019 00:00:00 +0000

For the last couple of years I have been consulting and doing contract work for various instant messaging companies. All of them use the Extensible Messaging and Presence Protocol (XMPP); Mostly with standard extensions on standard servers. There might be a custom extension here and there but nothing that couldn’t be written down as a standard. (I’m of course not implying that all companies use XMPP, but the ones that do might contract me because that’s my area of expertise.) Using XMPP works fine for those companies. Their products might not always be a success simply because it is difficult to launch an instant messenger in 2019 where even big companies like Google and Microsoft have failed numerous times. However some of them strive in their particular niche and I’m proud to have been working with them. From talking to other developers in the XMPP community I know that many of them have made similar experiences. While the open source side of XMPP admittedly looks pretty rough at times and can not unconditionally be recommended to end users, there are plenty of closed source solutions out there that don’t usually advertise themselves as being built upon XMPP. I’m saying all this to make one particular point: If you can look past some of the open source clients that are being developed by people in their spare time (and those make up what people usually perceive as the XMPP ecosystem) there are plenty of companies who have built successful services on top of the same protocol. However those services have one thing in common; None of them are federated and none of them make it particularly easy to connect with third party clients. From my experience this is mostly due to two reasons. The first reason – and that is pretty common with the more open companies; for example those who use and advertise their use of open source software – is quality control. They are afraid of people trying to connect with one of the bad open source clients (I’m sorry but I’m looking at you Pidgin) and have a bad user experience as a result of that.

Here lies the Sliding Pane Layout. RIP

Fri, 16 Mar 2018 00:00:00 +0000

A justification for some of the design choices I made; The second part in a series of essays leading up the release of Conversations 2.0

I had been a Jabber user for many, many years when I got my first Android device in 2012. It was around that time when Android received its first major UI overhaul called Holo. As a result the available Jabber clients all looked very dated to someone like me, who had never experienced the pre Holo UI first hand. The situation didn’t improve much over the next two years. Functionality aside, the pure aesthetics of Xabber and ChatSecure were enough to stop me from using Jabber on my new mobile phone and instead drove me towards using Hangouts. (For those who are not old enough to remember; Hangouts was one of many failed attempts from Google to step into the instant messaging market.) Despite all that I kept using Jabber on my desktop and kept wanting to use it on my phone as well. This ultimately lead me to the question on why those apps seemed to struggle with modern UI design. Finally in early 2014 I set out to answer that question and started to experiment and taught myself how to develop Android apps. My first task: A pixel perfect UI mockup clone of Hangouts with the working title »Secure Conversations« - A rather uninspired rip-off from »Chat Secure«, the name of one of the existing Jabber clients. Some weeks later, in my very own Facebook moment, a friend of mine, taking over the role of Justin Timberlake, would tell me to drop the »Secure«. But I’m getting ahead of myself.

The rocky road to OMEMO by default

Tue, 13 Mar 2018 00:00:00 +0000

Why it took us more than two years to enable End-to-End encryption by default: The first in a series of essays leading up to the release of Conversations 2.0

When Andreas Straub first introduced OMEMO into Conversations he was trying to make it work with existing server infrastructure by utilizing a general purpose storage mechanism called PEP to store the public key material. PEP, at that point, was primarily being used to distribute the user’s avatar. At least on paper it was also capable of storing group chat bookmarks and all kind of other information. By default only the contacts of a user are allowed to access the information stored in PEP. This default is perfectly reasonable for avatars and still gets you a long way when trying to use OMEMO - After all, most of the time you will be chatting with your contacts. Most of the time, but not always… There are two primary exceptions to that rule: Group chats, and the first few messages you exchange before adding each other to your contact lists. This was a big hurdle we had to overcome before being able to make OMEMO default for all outgoing messages. Unfortunately, efficiently changing the access model of a PEP node was, despite being standardized, not implemented in any of the major servers. Ejabberd, one of the major XMPP servers, got support for that in its 17.12 release. Prosody, another widely used XMPP server, is still working on that feature, but has a module called omemo_all_access that essentially disables access control for all OMEMO nodes and thus achieves the same effect.

Converse.js leaking information about which rooms are bookmarked

Fri, 02 Feb 2018 00:00:00 +0000

CVE-2018-6591: When storing bookmarks on the server Converse.js does not properly configure the access model to be private.

Introduction

The Personal Eventnig Protocol (PEP) is a commonly used extension (XEP) for XMPP. It is a subset of the more powerful Publish-Subscribe (XEP-0060), operating on the user’s account. Primarily it is being used to publish information like a user’s avatar or nick name, that should be visible to other contacts. Each type of information is stored on a different »node«. The default access model of a node is set to be readable by everyone with mutual presence subscription (=contacts). If desired the access model can be changed to being readable by everyone (=open) or to being only readable by the owner. However not every XMPP server supports changing the access model.

An Objection to ‘The ecosystem is moving’

Wed, 30 Nov 2016 00:00:00 +0000

In May 2016 Moxie Marlinspike published an article on his company’s blog entitled ‘Reflections: The ecosystem is moving’ where he claims that federated systems are ‘stuck in time’. Since then his blog post has been passed around primarily to support the argument that federated, XMPP based, instant messaging is not working and won’t ever provide a decent user experience. On the other hand his blog post is rarely used as an argument on how bad the World Wide Web is and on how we should all give up on using the Web, even though HTTP is one of the protocols Moxie claims to be stuck in time. In fact Moxie picks his examples very carefully and only talks about HTTP as being stuck in time. He ignores the fact, that on top of HTTP there is another standard called HTML, which is everything but stuck in time. HTML and related technologies like CSS and JavaScript have massively evolved in the last 20 years. Interestingly the Web is something where federation has improved. It’s not too long ago that the Microsoft Internet Explorer had a market share of well over 90%. The web was filled with websites, relying on non-standard extensions like Java Applets and Flash. Now those extensions are gone. The market is more or less equally divided between at least three major vendors. The decision on what webbrowser one uses is purely made on factors like speed, available plugins and is no longer dependent on what websites they are able to display.

Blind Trust Before Verification

Sun, 20 Nov 2016 00:00:00 +0000

Establishing trust is always a complicated task but especially difficult in a multi-device environment where every device has its own identity. Concepts like Trust On First Use (TOFU) don’t work very well because a malicious server could sneak a ‘surveillance device’ into every device announcement. Furthermore Trust On First Use doesn’t have an answer to users switching devices or otherwise reinstalling the App which would generate a new key. If you consider that an App or an identity is being used for 10+ years you can assume that every user will reinstall the App or get a new device at least once. Subsequently TOFU only prolongs the problem of having to make a manual trust decision. Signal and WhatsApp have recognized this and are moving to a trust-everything approach and merely warn users when fingerprints change. Train somebody long enough to ignore those warnings and you’ve essentially made End-to-End-Encryption completely useless. Imagine if we only used the Web with self signed certificates; Even cautious users would quickly adopt a behaviour of simply ignoring the warning. Of course you could drive to the bank and compare the certificate’s fingerprint in person, but in reality nobody is going to do that, especially if they keep changing every couple of months.

The State of Mobile XMPP in 2016

Thu, 02 Jun 2016 00:00:00 +0000

XMPP is not suited for mobile devices. That’s a myth that has been around for ages. It is mostly spread by people who want to sell you their own proprietary instant messaging solution. But it also gained some popularity through a blog post entitled The (Sad) State of Mobile XMPP in 2014 by Georg Lukas. While Georg wasn’t wrong with his status report per se, it is important to understand that he describes a temporary problem. There was a brief period of time where XMPP actually had some catching up to do. XMPP was fine before, when we had different requirements—In fact I was using an XMPP client on my Nokia E71 back in 2008 (That’s more than two years before WhatsApp was even invented)—and it’s fine now in 2016.

Gajim Roster Push Attack / Message Interception

Sun, 20 Dec 2015 00:00:00 +0000

CVE-2015-8688: Gajim doesn’t verify the origin of roster pushes thus allowing third parties to modify the roster.

Alice is using the latest version of Gajim (0.16.4) and logged in as alice@siacs.eu/Gajim. She has her boyfriend Bob (bob@siacs.eu) saved under Bob in her roster. Gajim shows Bob’s JID only in the tooltip of the respective roster entry.

Changing Roster Entries

Eve, jealous of Bob, wants to intercept Alice’s messages to Bob. She crafts two special stanzas (XMPP packets) and sends those to Alice.

Conversations: A Mission Statement

Mon, 14 Jul 2014 00:00:00 +0000

Conversations is a messenger for the next decade. Based on already established internet standards that have been around for over ten years Conversations isn’t trying to replace current commercial messengers. It will simply outlive them. Commercial, closed source products are coming and going. 15 years ago we had ICQ which was replaced by Skype. MySpace was replaced by Facebook. WhatsApp and Hangouts will disappear soon. Internet standards however stick around. People are still using IRC and e-mail even though these protocols have been around for decades. Utilizing proven standards doesn’t mean one can not evolve. GMail has revolutionized the way we look at e-mail. Firefox and Chrome have changed the way we use the Web. Conversations will change the way we look at instant messaging. Being less obtrusive than a telephone call, instant messaging has always played an important role in modern society. Conversations will show that instant messaging can be fast, reliable and private. Conversations will not force its security and privacy aspects upon the user. For those willing to use encryption Conversations will make it as uncomplicated as possible. However Conversations is aware that end-to-end encryption by the very principle isn’t trivial. Instead of trying the impossible and making encryption easier than comparing a fingerprint Conversations will try to educate the willing user and explain the necessary steps and the reasons behind them. Those unwilling to learn about encryption will still be protected by the design principles of Conversations. Conversations will simply not share or generate certain information for example by encouraging the use of federated servers. Conversations will always utilize the best available standards for encryption and media encoding instead of reinventing the wheel. However it isn’t afraid to break with behavior patterns that have been proven ineffective.