Planet Jabber

July 22, 2019


Seventh week: Socks 5 file transfer

The blog posts have slipped somewhat, last blog post covering two weeks. Let’s try to fix that.

The next step for file transfers was to implement more Jingle transport methods. Currently, only in-band bytestreams are implemented as transport methods. The inefficiencies have been discussed already, it mostly boils down to the fact that in-band bytestreams exchange base64-encoded data over the XMPP stream.

The next transport method to be implemented are SOCKS5 bytestreams (S5B, XEP-0065, XEP-0260). They can work in direct (peer-to-peer) or mediated (via a proxy server) mode, depending on whether the clients are visible to each other or whether they want to share their IP address.

SOCKS5 is a relatively simple protocol, it can basically be implemented after reading its Wikipedia page: After establishing a TCP connection to the proxy server, the client sends its available authentication methods, the server chooses one, the authentication happens. After successful authentication, the client specifies where it wants to connect to and the server acks that. Thereafter, one can use the TCP connection as if it was connected to the previously specified IP address, sending and receiving data as if one were connected directly.

SOCKS5 bytestreams use this protocol in a somewhat peculiar way. Instead of specifying IP addresses to connect to, the SOCKS5 proxy more or less acts like a rendez-vous point. Both sides that want to use the proxy as mediator connect to it, and specify a common but somewhat random fictional domain name to connect to. After one of the clients “activates” the connection via XMPP, data can flow between these clients.

In theory, this is just another Jingle transport method, so one wouldn’t have to modify the Jingle code to add it. However, since we only have one transport method yet, the abstractions are probably not quite right yet: For example, S5B needs support for <jingle action="transport-info">, which IBB didn’t.

Let’s see how this works out.

by hrxi at July 22, 2019 00:00

July 21, 2019

Ignite Realtime Blog

Smack 4.4.0-alpha2 released

@Flow wrote:

The Ignite Realtime developer community is proud to announce the availability of Smack 4.4.0-alpha2 .

This is the second alpha release of the upcoming Smack 4.4 version. Users are encouraged to test this version in their development branches. We are happy about our feedback.

Posts: 1

Participants: 1

Read full topic

by @Flow Florian Schmaus at July 21, 2019 09:21

July 17, 2019

Maxime Buquet

New Sprint, new goodies

On this weekend of Bastille day some of us gathered and worked around some interesting new features in XMPP implementations. Wisolv &ndash; tailor-made software development company &ndash; generously sponsored the venue and provided us with their office in Villeurbanne (next to Lyon). I think most of us are happy with this sprint, we managed to get quite some work done. On the agenda were DOAP, Message Reactions, Occupant-id, various fixes and discussions, also including work on a Jabber client for Haiku!

by pep. ( at July 17, 2019 10:45

July 16, 2019


Kaidan 0.4.1 released!

After some problems were encountered in Kaidan 0.4.1, we tried to fix the most urgent bugs.


  • Fix SSL problems for AppImage (lnj)
  • Fix connection problems (lnj)
  • Keep QXmpp v0.8.3 compatibility (lnj)


July 16, 2019 13:00

July 14, 2019

Jérôme Poisson

SàT progress note 2019-W28


remember last week when I was mentioning external things that I've put on hold? There was a Twisted ticket that I've opened months ago, I've made a pull request for that, but there was still some changes to do according to review.

Unfortunately, between my paid job, work on SàT, and real life things I haven't had the time to update it, and little after sending my last week note, I've got an email notification about the ticket being fixed (with a patch replacing mine). I was feeling a bit bad to let this for months and not finding the time to update it myself (in 8 months). Fortunately Twisted folks are nice and understand well ("No need to apologize. We're all volunteers here :)"), and it's a good thing that they managed to fix this issue.

I'm telling this because people don't always understand why things take time (why the release it taking so long? Why nobody did review my merge request?), or may be forgotten. It's just that people can be really really busy, and in free software communities, many of them work on their free time.

During this week, again, it was debugging: really useful for the project, but not so much to tell or explain. The blocker list is getting really low, and I feel fairly optimistic that release can be done next week.

There is maybe one issue I've come through that may worth a mention : while the new chat page of Libervia was working fine during my tests on localhost, it was not working at all once deployed. This is a really simple chat for now, just a proof of concept before adding advanced feature in next version. Libervia pages which come with the new web framework are currently mostly static (i.e. there is no advanced javascript to handle complex changes, this will come in next version), and the chat works by establishing a websocket with the pages, and just sending new messages to display. The web framework is supposed to make life of developer easier, and you only have to declare a dynamic = True variable to activate the websocket. In the background, Libervia create the websocket, associate the page with it, and also the request which is an object containing many useful data, including the session with the profile of the user.

While investigating, I've realised that the issue was happening only in HTTPS, so it was not visible while working on http://localhost. Happily, I'm now working mostly in HTTPS even during local development, this make the detection of this kind of issues easier. I've been using mkcert which makes the process of adding personal certificate painless, and thanks to it I can work easily in HTTPS on my own private and local domain.

This led to an issue with the request object I was storing. This Twisted object is not made to be stored this way, but I was doing it to keep the useful data it contains. Once the HTTP GET request used to retrieve the chat page is finished, the channel is closed, and it is used to test if the request is secure or not (the Twisted session is not stored in the same object or using the same cookie if the request is secured or not). As a result I was getting an empty session, like if the user was not connected, and the chat could not work. I could easily work around this issue, and I've reworked this in a cleaner way; it's working fine now.

The release is not totally ready yet, but I'm already thinking about what's coming next (beside Python 3 port), and there are several big options in my mind, it will be important to choose carefully the priorities. I'll probably focus soon on user experience (UX), as current UI (specially for Cagou), is not that intuitive and accessible for newcomers. I'll write more about this for the release note (which may replace next week progress note).

by goffi at July 14, 2019 13:21

July 13, 2019

Ignite Realtime Blog

Monitoring Service 1.8.0 and inVerse plugins released

@wroot wrote:

The Ignite Realtime community is happy to announce the release of two plugins that happened a few weeks ago (better later than never:))!

Monitoring Service 1.8.0 version brought plugin’s MAM implementation more up to date, fixed some bugs and improved performance.

inVerse version updated underlying Converse library to the latest 4.2.0 version, which has lots of fixes and improvements.

Your instance of Openfire should automatically display the availability of updates. Alternatively, you can download the new releases from the plugins downloads page.

For other release announcements and news follow us on Twitter

Posts: 2

Participants: 2

Read full topic

by @wroot wroot at July 13, 2019 12:25

July 09, 2019


Fifth and sixth week: File receiving

In the last two weeks, file receiving over Jingle has been implemented. This means that basic Jingle file transfers are available in Dino now (at least once the pull request #577 has been merged).

As predicted by the Jingle implementation gist, this was actually a bit more than I would have guessed – you basically have to implement the Jingle and file transfer protocol again, but this time from the other side. Doing so involved some refactoring of the original code in order to fit better with Dino’s internals. I moved the code from signal-style callbacks to async IOStreams.

by hrxi at July 09, 2019 00:00

July 08, 2019


Kaidan 0.4.0 released!

It’s finally here!

After more than one and a half years there finally is a new release. Kaidan 0.4.0 is the biggest update until now and apart from some bug-fixes and many minor and major features increasing the usability, Kaidan now has multiplatform-support for all common operating systems like Linux, Windows, Android and macOS.

But have a look at the changelog yourself:


Build system:

  • Support for Android (ilyabizyaev)
  • Support for Ubuntu Touch (jbb)
  • Support for macOS (ilyabizyaev)
  • Support for Windows (ilyabizyaev)
  • Support for iOS (ilyabizyaev)
  • Add KDE Flatpak (jbb)
  • Switch Android builds to CMake with ECM (ilyabizyaev)
  • Improve Linux AppImage build script (ilyabizyaev)
  • Add additional image formats in AppImage (jbb)

New features:

  • Show proper notifications using KNotifications (lnj)
  • Add settings page for changing passwords (jbb, lnj)
  • Add XEP-0352: Client State Indication (gloox/QXmpp) (lnj)
  • Add media/file (including GIFs) sharing (lnj, jbb)
  • Full back-end rewrite to QXmpp (lnj)
  • Implement XEP-0363: HTTP File Upload and UploadManager for QXmpp (lnj)
  • Use XEP-0280: Message Carbons from QXmpp (lnj)
  • Use XEP-0352: Client State Indication from QXmpp (lnj)
  • Check incoming messages for media links (lnj)
  • Implement XEP-0308: Last Message Correction (lnj, jbb)
  • Make attachments downloadable (lnj)
  • Implement XEP-0382: Spoiler messages (xavi)
  • Kaidan is now offline usable (lnj)
  • Kaidan is able to open xmpp: URIs (lnj)
  • New logo (ilyabizyaev)
  • Show presence information of contacts (lnj, melvo)
  • Add EmojiPicker from Spectral with search and favorites functionality (jbb, fazevedo)
  • Highlight links in chat and make links clickable (lnj)
  • New about dialog instead of the about page (ilyabizyaev)
  • Add image preview in chat and before sending (lnj)
  • Send messages on Enter, new line on Ctrl-Enter (ilyabizyaev)
  • ‘Add contact’ is now the main action on the contacts page (lnj)
  • Elide contact names and messages in roster (lnj)
  • Chat page redesign (ilyabizyaev)
  • Display passive notifications when trying to use online actions while offline (lnj)
  • Automatically reconnect on connection loss (lnj)
  • Contacts page: Display whether online in title (lnj)
  • Add different connection error messages (jbb)
  • Use QApplication when building with QWidgets (notmart)
  • Ask user to approve subscription requests (lnj)
  • Remove contact action: Make JIDs bold (lnj)
  • Add contact sheet: Ask for optional message to contact (lnj)
  • Add empty chat page with help notice to be displayed on start up (jbb)
  • Redesign log in page (sohnybohny)
  • Add Copy Invitaion URL action (jbb)
  • Add ‘press and hold’ functionality for messages context menu (jbb)
  • Add copy to clipboard function for messages (jbb)
  • Add mobile file chooser (jbb)
  • Highlight the currently opened chat on contacts page (lnj)
  • Remove predefined window sizes (lnj)
  • Use new Kirigami application header (nicofee)
  • Make images open externally when clicked (jbb)
  • Use QtQuickCompiler (jbb)
  • Display upload progress bar (lnj)
  • Add text+color avatars as fallback (lnj, jbb)
  • Remove diaspora log in option (lnj)


  • Forget passwords on log out (lnj)
  • Append four random chars to resource (lnj)
  • Save passwords in base64 instead of clear text (lnj)
  • Generate the LICENSE file automatically with all git authors (lnj)
  • Store ubuntu touch builds as job artifacts (lnj)
  • Add GitLab CI integration (jbb)


  • Fix blocking of GUI thread while database interaction (lnj)
  • Fix TLS connection bug (lnj)
  • Don’t send notifications when receiving own messages via. carbons (lnj)
  • Fix timezone bug of message timestamps (lnj)
  • Fix several message editing bugs (lnj)
  • Fix black icons (jbb)
  • Fix rich text labels in Plasma Mobile (lnj)
  • Small Plasma Mobile fixes (jbb)

Bug reports go to our issue tracker as always and translations are managed on Weblate.


PS: We’re searching for someone with an iPhone who can build & test Kaidan for iOS: contact us!

July 08, 2019 13:00

July 07, 2019

Peter Saint-Andre

Aristotle Research Report #11: εὐπραξία

One of the lesser-known terms in Aristotle's ethical treatises is εὐπραξία (eupraxia) along with its sister εὐπραγία (eupragia). Both terms mean doing well, faring well, having success. Aristotle's use is connected to εὐδαιμονία, which he defines as "living well and doing well" (τὸ εὖ ζῆν καὶ τὸ εὖ πράττειν). But what are the metrics for "success" here? He leaves us several clues. First is the verb πράττειν, which for Aristotle means not merely engaging in activity but taking action, typically as the outcome of making a decision (this is why he thinks that, strictly speaking, animals and children do not "take action" even though they are clearly active physically and biologically). Second is that Aristotle contrasts εὐπραξία with εὐτυχία or good fortune; success is a matter of achievement, not luck....

July 07, 2019 00:00

July 05, 2019

Jérôme Poisson

SàT progress note 2019-W27


this week note will be short, first because I've mainly fixed bugs, second because I've pain in my wrist and it's not comfortable to write.

The most visible part of this week work is the addition of some installation instructions on the front page of, which render like this:

capture of installation icons from

(this is a screenshot, this image is not clickage, check to see the real clickable version)

Thanks to the work explained in previous notes, we're getting closer to an easy installation in a few clicks. We're not exactly there yet though, as Flatpak still needs to be installed in most distributions (I think, I don't know exactly where it's installed by default), Libervia (web frontend) is not installed this way (but I'll update the Docker image at some point which is also easy to install/run), and there are maybe other tweaks to do (for instance on Android you must activate the installation from external sources). Please note than when SàT is available natively in the distribution, it's the recommended way to install it.

Also the many ways to install + different frontends/versions (and I've not put yet Libervia + packages for others platforms like Windows or Mac OS) may be confusing. Maybe a platform detection could help to highlight the most probable package in the future.

Another thing which can cause trouble with SàT specific architecture is the backend: for Flatpak I've made a wrapper to launch it automatically if it's not already, otherwise the running backend is used. It works but there is a risk of troubles when the package will be updated and the running backend version may be older than the expected one. I'll have to modify the backend to check that at some point (probably in 0.8).

An other necessary improvement for 0.8 will be the login screen: for now it's really confusing for somebody not used to XMPP (you have to create a profile with a jid and a password, then click on it, then you land to widget selector). I have several ideas on how to change that, but I'll work on it only after release and python 3 port.

That's all for this week note, as I've said in the first paragraph I've mainly done debugging which is not really interesting to explain here. I'm a bit annoyed to lack the time to do more, as I've put aside some external things that I need to finish: I have 2 XEPs to update, and a pull request for Twisted that I've opened months ago and I need to update too. I haven't had much time either to follow standard mailing list, which is a pity because some really interesting things are happening there like the long awaited full stanza encryption.

I hope to be able to fix enough bugs in the incoming week to finally release the 0.7, I'm looking forward for it, and I'm sorry that the release will happen during the summer when many people will be on holidays (well I'm happy for people being on holidays, it's just that it's not the best time to have the release being noticed).

by goffi at July 05, 2019 10:44

July 03, 2019


Uniting global football fans with an XMPP geocluster

When you are running one of the top sport brands, launching a new innovative app always means it comes with great expectations from your fans.

That’s why highly recognised brands turn to ProcessOne. They need to be sure that the project will launch in time, will perform well and will not collapse under the load, no matter what happens.

In early 2014, a top brand contacted us with a clear and ambitious project in mind. We had 6 months to develop and host the infrastructure for a large-scale realtime communication and messaging project. The deadline was not flexible. The app needed to be live just before the FIFA World Cup in Brazil.

ProcessOne worked with the customer mobile team to help them accelerate their development. XMPP can be a complex protocol and if you wish to launch with a tight deadline, you need to take a “fast lane” approach and get help directly from experts.

We also had to host the project, providing low-latency for connection and messaging everywhere in the world. We deployed a geocluster, handling a single XMPP domain in four data centers across the world. We operated our deployment in 4 AWS regions: USA to serve North America, Brazil to serve South America, Singapour to serve Asia and Ireland to serve Europe.

We used our custom Erlang component to deploy a geocluster at scale, handling ourselves all database synchronization across regions and auto-recovery in case of netsplits.

The application was ready just in time to handle the load of fans installing and trying the app. Soon after the launch we had to handle an unexpected 10x peak load when Cristiano Rolnaldo, with tens of millions of followers, retweeted about the app — and the platform handled it without a flinch!

With a 100% uptime, the project was a success, and the app gathered hundreds of thousands of football fans from all over the world. Did you guess which brand it was?

Areas of expertise:
– Realtime messaging
– Push notifications
– Platform management / hosting

– Backend: Erlang / XMPP / ejabberd

by Marek Foss at July 03, 2019 13:05

June 30, 2019

Monal IM

OpenFire push plugin!

If you run an open fire server and want to use Monal, use this plugin to get push support.

by Anu at June 30, 2019 02:43

June 29, 2019

Monal IM

Open fire push support

We are currently testing a plugin that has been developed to support push on oepnfire .I am happy to report preliminary tests have been positive. This is something that will help a lot of people use monal on their existing servers.

by Anu at June 29, 2019 16:34

Ignite Realtime Blog

Openfire 4.4.0 Release

@akrherz wrote:

The Ignite Realtime Community is thrilled to announce the release of Openfire version 4.4.0. This is a major release featuring stability improvements and new features. You can find a full changelog listing over 100 Jira Issues resolved. Our beta announcement of this release highlighted some of the most significant changes. Of note is that this release should properly work with Java 11 and using OpenJDK as well. The minimum requirement is Java 8.

You can find downloads for Openfire with the following sha1sum values for the release artifacts.

c0d92cf54b02fe005b83a90256ddcfdfadad3c3c  openfire-4.4.0-1.i686.rpm
70b7570ae3f5ef48e3a2f4772dbeacaf22360b70  openfire-4.4.0-1.noarch.rpm
0ba75846af64b4379130b0b1835ba17899bb3593  openfire-4.4.0-1.x86_64.rpm
36cd9fd38e3840f9afa0d2cc5c86bbbe4a029569  openfire_4.4.0_all.deb
e4687a8f346741de9e4a502ddd63e2c55c7f4c3c  openfire_4_4_0_bundledJRE.exe
1437874597334f534e7d7882b02d550c3d5daec0  openfire_4_4_0_bundledJRE_x64.exe
8b579ca4441c6ca2502ffe9d2e3fdd27bc4190a6  openfire_4_4_0.dmg
e9b311e4d44b53f796a65c8f75abf4e39890dccb  openfire_4_4_0.exe
3205889dc1e7251b15d2dedacea3cfbbbf594810  openfire_4_4_0.tar.gz
00e1f28db47fd82653af6e1736bc036b344ecae2  openfire_4_4_0_x64.exe
285176004dccf7d07361064d558ee48579b65c5f  openfire_src_4_4_0.tar.gz

The previous release of Openfire 4.3.2 was made on January 31rst, 2019 and here’s a simple accounting of the 100,000+ downloads made of the software!

Openfire Download Stats for Release: 4.3.2
             openfire-4.3.2-1.i686.rpm   2038
           openfire-4.3.2-1.noarch.rpm   2508
           openfire-4.3.2-1.x86_64.rpm   9869
                openfire_4.3.2_all.deb  18521
                    openfire_4_3_2.dmg   2406
                    openfire_4_3_2.exe   9492
                 openfire_4_3_2.tar.gz   6861
         openfire_4_3_2_bundledJRE.exe   4158
     openfire_4_3_2_bundledJRE_x64.exe  19909
                openfire_4_3_2_x64.exe  24528
             openfire_src_4_3_2.tar.gz    319

With the release, our Github master branch now reflects a future potential release version of Openfire 4.5.0 and we have also created a 4.4 branch signifying our intention to produce a 4.4.x series of bug fixes. We presently do not have plans of making a 4.3.3 release from the 4.3 branch.

Massive thanks for this release go to @gdt and @guus. They both did lots of great work knocking out some nagging issues and improving the already great administration console. It was also encouraging to see a number of first time contributors submitting pull requests with fixes and new features.

We certainly would encourage folks to test out the new release and report issues in the community forums. Please also free free to stop by our group chat and tell us now the new release is going. We are always looking for people interested in helping out with development, documentation, and testing.

Thank you for your support and usage of Openfire!

Posts: 8

Participants: 4

Read full topic

by @akrherz daryl herzmann at June 29, 2019 02:51

June 28, 2019

The XMPP Standards Foundation

The XMPP Newsletter, 28 June 2019

Welcome to a bumper edition of the the XMPP newsletter, containing news from the last two months.

If you have an article, tutorial or blog post you'd like us to include in the newsletter, please submit it on the XMPP wiki.


Mickaël Rémond from ProcessOne has written about how the Nintendo Switch uses ejabberd for push notifications. He explains why XMPP was chosen as protocol, why ejabberd was chosen as the server and the performance tuning they had to do so that the Nintendo Switch push service can now handle 10 million simultaneous connections and 2 billion messages per day.

Recently a German politician, Katarina Barley of the Social Democrats, tweeted that she'd like to see regulation in the instant messaging space where messengers are forced to interoperate similarly to wireless carriers. Many people responded to her tweet, saying that this is impossible or undesirable. Daniel Gultsch, author of the Conversations and Quicksy Android clients, has written a thoughtful post on why he thinks regulation is indeed necessary to create interoperability between instant messengers.

Peter Saint-Andre wrote a short post on being invited to become co-author of RFC 8600 XMPP Grid.

Kaidan, an XMPP client, has joined KDE.

Movim is the the first XMPP-based app that has added emoji reactions to messages, in both one-on-one conversations and groupchats, by making use of XEP-0367: Message Attaching. You can now support the project on Patreon.

Heather Ellsworth from Purism has written a progress note for the Librem 5. A notable messaging-related change is that the Lurch OMEMO plugin, used in Librem's Chatty messenger, has received a lot of updates recently.

Goffi is keeping us informed about his progress on Salut à Toi by writing weekly progress notes. Recently he published notes for weeks 24, 25 and 26.

Kiran Jasvanee has written an introductory piece on XMPP, explaining protocol features such as Jabber IDs, extensibility and streams.

Mickaël Rémond wrote down some thoughts on code style in library design focusing on designing an API for the Fluux XMPP library.

Anurodh Pokharel (aka Anu) has written about a first experimental Mac Build of Monal using Catalyst.

Arnaud Joset has written guides to using sat-pubsub, the PubSub component from the Salut à Toit project, and JP, a powerful command line interface for Salut à Toit.


Openfire developer Guus der Kinderen has written a summary of the recent XMPP Sprint in The Hague. Much of the work revolved around better support for push notifications. Multiple clients and servers were represented and being worked on.

Another XMPP Sprint is coming in Lyon, France, on 13-14th of July.

Software releases


ProcessOne has released ejabberd 19.05, improving MIX and MucSub.

Ignite Realtime has released Openfire 4.4.0 beta.

Erlang Solutions has released MongooseIM 3.4.0 with a strong focus on GDRP compliance.


Conversations 2.5.0, 2.5.1, 2.5.2 added public channel search via and reworked onboarding screens.

Monal 3.8 for iOS makes onboarding easier for non-technical users, as the new registration screen is easier and faster.

BeagleIM (for macOS) and SiskinIM (for iOS), brought to you by Tigase, now both support the OMEMO end-to-end encryption protocol.


Strophe.js, the JavaScript XMPP library (published under the MIT license) has released version 1.3.3.

Google Summer of Code

The XSF has announced its participation in the Google Summer of Code 2019. The selected projects are:

Prosody plugin installer, by João Duarte Poezio infinite scrolling using MAM, by Madhur Garg Jingle File Transfer for Dino, by hrxi


The Debian XMPP Team has launched a blog.

Conversation's server compliance tester has been redesigned and is now easier to navigate.

Tigase is now a Gold sponsor of the XSF.

by jcbrand at June 28, 2019 12:00

Jérôme Poisson

SàT progress note 2019-W26

Hello everybody,

I was targeting end of June for the release, it seems that I'll have to postpone: it's not ready yet, there are still a couple of annoying bugs. That's a really boring part from a developer point of view, you have to take care of polishing, and things around the code (like the website, documentation or packaging), and you don't see your project evolving much. It's far more exciting to work on new features or experiments, but you need to go through polishing if you want something usable.

I've been talking about Flatpak last week, I still had to do some work on it.

After getting working packages for Cagou, Primitivus and Jp, I've created a repository for that ( and the flatpakref files which are metadata telling where to find and how to install the packages. I was happy to finally have a simple way to install Cagou so people could test it and give feedback, so I've sent a short notice on Diaspora and ActivityPub. I've indeed quickly got feeback reporting the outdated runtime (1.6 while 18.8 is now available, I've just missed it while working with my Manifest from last year), then I had to update the package again.

Once again, feedback has been useful (thanks JBB), so please if you see something buggy or you would like to see something (new feature or anything), let me know!

During my own test I realised that the MIME type for the flatpak refs files was wrong too (it was text/html so the browser was displaying them instead of downloading them). That was a bad default value used in Libervia, and it's now fixed.

After updating the runtime, testing it successfully without installation (using flatpak-builder --run build-dir org.gimp.GIMP.json sat_wrapper) and uploading it, I've had the bad surprise to realise that python2 was missing when trying to run the package normally. It is actually available in the SDK so it was working while testing with flatpak-builder, but not anymore in the runtime (which make sense as Python 2 support will be stopped next year, but still SàT is using it and will move to Python 3 for 0.8 release). So I had to compile Python 2 myself, and make several try to make it work correctly (and that's only after it worked that I have discovered that there was a pre-made module offered by Flatpak teams).

All of that to get this thing:

Cagou flatpak package seen on KDE Discover

Integration in the package manager (here Discover from KDE) is nice to have, and I hope that it will be the case by default in most distributions in some time. I'll propose the package on Flathub (the central repository of Flatpak) once the stable release is out.

There are still some little issues on the package/metadata (like the screenshot which are not at the recommended 16:9 format), but I'll take care of them later, I have already spent enough time there and I need to move forward. Furthermore, the screenshots seem to be displayed correctly beside their format on KDE Discover and GNOME Software.

Far more serious, there are some crashes on the Flatpak version of Cagou (I've had a infinite recursion crash when clicking on bookmarks) that I don't have on normal packages, so I have to debug that but that's part of the general debugging phase I'm now in.

To install dev preview packages of Cagou, Primitivus or Jp from Flatpak, just enter the following commands:

  • flatpak install --user
  • flatpak install --user
  • flatpak install --user

And later to update them:

  • flatpak update

Or use your graphical software manager. I'll add the links to the website soon, so it should be installable in a few clicks.

Remember that it's dev version, so expect bugs, and in addition there are still some issues specific to the Flatpak version that I'll try to fix today.

That's really a lot of time spent on those packages, but I now have scripts which will help to updates everything easily. Imagine if I had to do all packages myself for every GNU/Linux distributions + Docker + Flatpak + AppImage + Snap + YunoHost + Android + *BSD + Windows + Mac OS + … . I'm already doing several on this list, but I can't do everything alone, so if you feel you can help on packaging, please contact me (see address at the bottom of or join us in our official room at or via web). Note that there are already people working on Arch packages and on Debian and derivatives (but they need help).

So now it's all about debugging and documentation until the release.

by goffi at June 28, 2019 07:28

João Duarte

Remainder of GSoC's first phase summary

A long way to climb

End of first phase is here! This post reflects last weeks' development as I juggle hands and feet through the climb.



- Added support for luarocks:
  • admin-add (Flags supported: --tree, --server, --no-refresh, --help)
  • admin-remove (Flags supported: --tree, --server, --no-refresh, --help)
  • list commands(Flags supported: --tree, --help)
- Various bug fixes, to make added functions comply with prosodyctl functionality and coding style

Software usage

- Solved some issues I was having when using ZeroBrane's studio to debug
- Tinkering around the creation of rocks and rockspecs from mod_smacks


- Still clumsy using different tools, like ZBS's IDE, Mercurial and Luarocks
- Some challenges with blog posts formatting

Future goals

- Enabling and disabling the mod_smacks plugin through prosodyctl 


Albeit still going too slowly for my taste, some progress is being made in most fronts. University evaluation period will be over next week, and in the mean time I feel more efficient using different tools when working on prosody. Picked up some of my notes from these last weeks and I'm intending in publishing them as blog posts. The idea is that they'll be half tutorial, for those unfamiliar with a particular tool, and the other half is how it allowed me to solve some problems along the way. Unexpectedly, when I published my ZeroBrane post, I noticed some issues with blogger converting text into HTML. Whether it was its fault or mine, formatting was totally a mess and I ended up using more time than what I wanted to. Hope things go better, if I make it through this first phase O.o

by João Duarte ( at June 28, 2019 00:30

June 27, 2019

João Duarte

Using ZeroBrane Studio to understand prosodyctl

Working on the terminal

One way to work on code is by using the terminal. We can navigate through folders and edit files with something classic, like Vim. The first time I was introduced to programming though, was through an IDE. Therefore, I always felt kind of uncomfortable working with code on something other than that. Even though nowadays I casually code with the terminal I always look for a neat IDE to use, albeit I know there isn't nothing I can do there that I can't do already through the normal tools. But that visual sugar, buttons and accessibility 😚 ...

One example

Okay, so here is the kind of situations were I like to use an IDE. I've made some coding on one of prosody's script, "prosodyctl", which is a script that contains commands to control prosody, in a systemctl-like fashion. This is a custom prosody installation I did from source, so everything is nicely packed in the same folder, making it easier to work around and develop. Here you can see my custom function, commands.list, which is simply executing a luarocks function which lists the installed rocks on a particular folder.

Now, if I was in my working folder and I executed the unchanged prosodyctl command, I'd get some information about the script as output. This is to help users who are working with the tool and might not be familiar with the commands, for example. However, after I coded my function, something unintended is happening:
When I run the prosodyctl script, it is executing my newly added command, and it's printing the output randomly with the default helper output.
How, why, when, where?
Something is clearly wrong, because there are plenty other command functions whose output is not printed when we run the script.

Using ZeroBrane Studio

For starters

We clearly need to debugged our script now, and we'll be using ZeroBrane Studio to do it. There might be better options to debug, but hey, we can only use what we know, until our knowledge progresses. So far, I personally like this method, albeit my opinion might change tomorrow. Worst case scenario, it won't hurt knowing how to use this tool.
Here are the links to download and install it!
So the first thing we want to do is changing the project directory. Doing so allow us to see the files and folders in that directory in the project tab and have an easier time around working. We can do it by going to:
Project -> Project Directory -> Choose

Interpreter is important!

We open the prosodyctl script and we try to run it. This is what was shown to me in the output window, the first time I was trying this out:
Which is strange. The script runs normally when we use the terminal, why wouldn't it here?
Well, one thing we can try out is comparing the Lua versions we are executing the script with. ZeroBrane comes with a lot of different interpreters. In my case, when I went to
project -> Lua interpreter
I had the the lua5.3 interpreter selected. Adding the line
At the beginning of the script also confirmed I was using lua's 5.3 version, which is different from what I had in the terminal, which was lua5.2.4 Stubbornly, even when I chose the lua5.2 interpreter I still couldn't run the script
Program 'lua52' started in '/home/joao/Documents/prosody_development/prosody-contrib' (pid: 10896).
Prosody was unable to find luaexpat
This package can be obtained in the following ways:
Debian/Ubuntu: sudo apt-get install lua-expat
luarocks: luarocks install luaexpat
luaexpat is required for Prosody to run, so we will now exit.
More help can be found on our website, at
Program completed in 0.07 seconds (pid: 10896).

Lets fix this problem by linking ZeroBrane directly to the same lua executable that our terminal is using. Usually, it will be located at
If, for whatever reason, you installed it somewhere else, you will have to find it. We will then reconfigure our 5.2 lua interpreter at ZBS by going to:
Edit -> Preferences -> Settings: User
This will open a file, where we'll paste this:
path.lua52 = "/usr/bin/lua"
That was my lua's path, but yours might be different. Anyway, now we just need to restart Zerobrane, select our lua5.2 interpreter, and we should be good to go!

The ZeroBrane and my terminal's output is now the same!


One of the main reasons why I like using IDEs are their debugging capabilities, which depend on the particular tool we are using. So far, I've liked ZeroBrane's.
Lets see it in action! We want to find out where our script is printing the unintended text. Here is how I found it out:

We start debugging here

Green triangle indicates which part of the script we are currently executing
1 - We place the cursor here
2 - This button will make the script execute until the line were the cursor currently is
3 - Notice we have no output at this point. That startup process isn't were the problem is

Those four similar buttons near arrow 2 allows us to use the debugger. Each one is useful and has a specific purpose, like stepping into a function or going right over it. On top of that we have a lot of extra functionality, which I'll not cover here because we are focusing on the workflow, instead of explaining all the functionality, which is very well detailed here!
We can eventually run through the script until we can pinpoint which part of the is causing the problem. Of course that, when we perfectly know our code, we should have a basic idea where it is. But sometimes we don't, and sometimes we are just working on someone else's code, like I am right now. There just isn't enough time to perfectly get to know all of it.
Anyway, I ended up discovering that the culprit was hiding inside this part of something called the command runner:

Understanding prosodyctl

Anyone really familiar with prosody's code won't be surprised with this discovery. Of course it had to be here!
Here is part of how this script works:
  • We go through a startup process, which sets and loads everything we need
  • Next, we have the script's main functions, like 'adduser', 'start' and my 'list'
  • Some stuff related to ejabberdctl and certificates
  • Declaration of the command_runner object
  • The command_runner call, which starts everything
In spite of having more than 1400 lines, our script is executed somewhere in the last 80, in our command_runner object. When prosodyctl is executed without any argument, this guy will go through here:

Right off the bat we can see something is amiss. My new commands aren't listed there. So that's a possible improvement. However, this still isn't where the problem really is. The code first executes a loop through the variable "commands_order" and then another one through "commands". This second variable is a table with all the commands in the script that something, somewhere, was able to find, including the ones I added. We can conclude this by inspecting what Zerobrane calls, the "stack", which, among other things, presents all the local variables and upvalues for the current stack frame.

The "commands" variable in the stack. We can see some of my functions, admin_remove and local_plugins
So, the script will call each function and pass the "--help" argument, even when it isn't listed on the "commands_order" variable. Since my functions don't know how to deal with that situation, they are simply run normally, which results in them printing out unwanted stuff.
Notice how the command "adduser"'s code starts and how my "local_plugins" lacks that functionality
We now know what needs to be done. By looking at the "adduser" command, for example, I added similar help functionality to my code, making it work as intended and complemented the "commands_order" variable.

After this, I got the expected output when executing prosodyctl

Wrapping it up

We used Zerobrane studio to execute prosodyctl around. I show how I deal with some problems along the way, both in using the IDE and on debugging my code on prosodyctl.

by João Duarte ( at June 27, 2019 23:30

Erlang Solutions

MongooseIM 3.4: Designed with privacy in mind

Let’s face it. We are living in an age where all technology players gather and process huge piles of user data, starting from our behavioural patterns and finishing on our location data. Hence, we receive personalized emails from online retail stores we have visited for just a second or personalized ads of stores in our vicinity that are displayed in our social media streams.

Consequently, more and more people become aware of how their privacy could be at risk with all of that data collection. In turn, the European Union strived to fight for consumer rights by implementing privacy guidelines in the form of the General Data Protection Regulation (GDPR), which governs how consumer data can be handled by third parties. In fact, over 200,000 privacy violation cases have been filed during the course of the last year followed with over €56m in fines for data breaches. Therefore, the stakes are high for all messaging service providers out there.

You might wonder: “Why should this matter to me? After all, my company is not in Europe.” Well, if any of the users of your messaging service are located in the EU, you are affected by GDPR as if you would host your service right there. Feeling uneasy? Don’t worry, MongooseIM team has got you covered. Please welcome MongooseIM release 3.4 that brings us full GDPR compliance.

Privacy by Design

A new concept has been defined with the dawn of GDPR - privacy by default. It is assumed that the software solution being used follows the principles of minimising and limiting, hiding and protecting, separating, aggregating, as well as, providing privacy by default.

Minimise and limit

The minimise and limit principle regards the amount of personal data gathered by a service. The general principle here is to take only the bare minimum required for a service to run instead of saving unnecessary data just in case. If more data is taken out, the unnecessary part should be deleted. Luckily, MongooseIM is using only the bare minimum of personal data provided by the users and relies on the users themselves to provide more if they wish to - e.g. by filling out the roster information. Moreover, since it is implementing XMPP and is open source, everybody has an insight as to how the data is processed.

Hide and protect

The hide and protect principle refers to the fact that user data should not be made public and should be hidden from plain view disallowing third parties to identify users through personal data or its interrelation. We have tackled that by handling the creation of JIDs and having recommendations regarding log collection and archiving.

What is this all about? See, JIDs are the central and focal point of MongooseIM operation as they are user unique identifiers in the system. As long as the JID does not contain any personally identifiable information like a name or a telephone number, the JID is far more than pseudo-anonymous and cannot be linked to the individual it represents. This is why one should refrain from putting personally identifiable information in JIDs. For that reason, our 3.4 release includes a mechanism that allows automatic user creation with random JIDs that you can invoke by typing ‘register’ in the console. Specific JIDs are created by intentionally invoking a different command (register_identified).

Still, it is possible that MongooseIM logs contain personally identifiable information such as IP addresses that could correlate to JIDs. Even though the JID is anonymous, an IP address next to a JID might lead to the person behind it through correlation. That is why we recommend that installations with privacy in mind have their log level set to at least ‘warning’ level in order to avoid breaches of privacy while still maintaining log usability.

Separate and aggregate

The separate principle boils down to partitioning user data into chunks rather than keeping them in a monolithic DB. Each chunk should contain only the necessary private data for its own functioning. Such a separation creates issues when trying to identify a person through correlation as the data is scattered and isolated - hence the popularity of microservices. Since MongooseIM is an XMPP server written in Erlang, it is naturally partitioned into modules that have their own storage backends. In this way, private data is separated by default in MongooseIM and can be also handled individually - e.g. by deleting all the private data relating to one function.

The aggregation principle refers to the fact that all data should be processed in an aggregated manner and not in one focused on detailed personal cases. For instance, behavioural patterns should be representative of a concrete, not identifiable cohort rather than of a certain Rick Sanchez or Morty Smith. All the usage data being processed by MongooseIM is devoid of any personally identifiable traits and instead tracks metrics relevant to the health of the server. The same can be said for WombatOAM if you pair it with MongooseIM. Therefore, aggregation is supported by default.

Privacy by default

It is assumed that the user should be offered the highest degree of privacy by default. This is highly dependant on your own implementation of the service running on top of MongooseIM. However, if you follow our recommendations laid out in this post, you can be sure you implement it well on the backend side, as we do not differentiate between the levels of privacy being offered.

The Right of Access

According to GDPR, each user has the right of access to their own data that’s being kept by a service provider. That data includes not only personal data provided by the user but also all the derivate data generated by MongooseIM on its basis. That includes data held in mod_vcard, mod_roster, mod_mam, mod_offline, mod_pubsub, mod_private, mod_inbox, and logs. If we add a range of PubSub backends and MAM backends to the fray, one can see it gets complicated.

With MongooseIM 3.4 we have put a lot of effort in order to make the retrieval as painless as possible for system administrators that oversee the day to day operations. That is why we have developed a mechanism you can start by executing the retrieve_personal_data command in order to collect all the personal and derivative data belonging to a user behind a specific JID. The command will execute for all the modules no matter if they are enabled or disabled. Then, all the relevant data is extracted per module and is returned to the user in the form of an archive.

In order to facilitate the data collection, we have changed the schemas for all of our MAM backends. This has been done to allow a swift data extraction since up till now it was very inefficient and resource hungry to run such a query. Of course, we have prepared migration strategies for the affected backends.

The Right to be Forgotten

The right to be forgotten is another one that goes alongside the right of access. Each user has the right to remove their footprint from the service. Since we know retrieval from all the modules listed above is problematic, removal is even worse.

We have implemented a mechanism that removes the user account leaving behind only the JID. You can run it by executing the “unregister” command. All of the private data not shared with other users is deleted from the system. In contrast, all of the private data that is shared with other users - e.g. group chats messages or PubSub flat nodes - is left intact as the content is not only owned by one party.

Logs are not a part of this action. If the log levels are set at least to ‘warning’, there is no personal data that can be tied to the JIDs in the first place so there is no need for removal.

Final Words on GDPR

The elements above make MongooseIM fully compliant with the current GDPR. However, you have to remember that this is only a piece of the puzzle. Since MongooseIM is a backend to a service there are other considerations that have to be fulfilled in order for the entire service to be GDPR compliant. Some of these considerations include process-oriented requirements of informing, enforcing, controlling, and demonstrating that have to be taken into consideration during service design.


Please feel free to read the detailed changelog. Here, you can find a full list of source code changes and useful links.

Test our work on MongooseIM 3.4 and share your feedback

Help us improve MongooseIM:

  1. Star our repo: esl/MongooseIM
  2. Report issues: esl/MongooseIM/issues
  3. Share your thoughts via Twitter
  4. Download Docker image with new release.
  5. Sign up to our dedicated mailing list to stay up to date about MongooseIM, messaging innovations and industry news.
  6. Check out our MongooseIM product page for more information on the MongooseIM platform.

June 27, 2019 09:24


Fourth week: Some UI integration

File sending over Jingle (with in-band-bytestream transport) has now been integrated into the UI. This has fortunately been quite easy as Dino already had support for file sending, via HTTP uploads. Thus I only needed to hook into the existing UI to also offer Jingle file transfers. This means that now you can click on the “attach” paper clip to send a file. Since prioritization of different transport methods and file receiving haven’t been implemented so far, these changes aren’t in the master branch yet.

Prioritization is important so that HTTP file uploads are preferred where possible (file small enough, server supports it): Jingle file transfers only work to a single target and only when it is online at the same time as the sender.

Since the ability to receive files via Jingle can also be reasonably expected if the client supports sending them, we basically have two blockers for merging.

Screenshot of Dino showing the paper clip button and a lot of file transfers

Above you can see the chat window after some testing. ;)

by hrxi at June 27, 2019 00:00

June 26, 2019

Peter Saint-Andre

RFC 8600: XMPP Grid

Sometimes you provide so much feedback on an Internet-Draft that the authors ask you to become a co-author. Such was the case with draft-ietf-mile-xmpp-grid, which defines a method for using XMPP to exchange information about security incidents (e.g., via the IODEF format) on a controlled-access network. The resulting standard (RFC 8600) is a rare example of what the IETF standards process document defines as an "Applicability Statement" (another recent example is RFC 8036). This is the 45th RFC I've authored or co-authored, which shockingly enough is one more than Vint Cerf - not that my contributions to the Internet are nearly as important as his!...

June 26, 2019 00:00

June 25, 2019


Breaking 25 trillion notifications for the BBC

In 2012, BBC needed to add a push notification service to its portfolio of mobile applications, with main focus on BBC News and BBC Sports. At the scale of the BBC, there was several key requirements that made it difficult to use an off-the-shelf application:

  1. A large number of deployed applications, in tens of millions. By adding push notification support to their new app, they would expect all updated apps to immediately contact the push notification backend. They needed to be 100% sure that the push backend would handle that massive load from day one.

  2. Ability to send as many pushes as the News would require. Most platforms pricing is based on the number of push delivered. It means that if you want to control your budget, you have to micro manage the push notifications you would send. This was not acceptable for the BBC.

  3. Pushes should be delivered quickly and faster than the competition. When sending breaking news, the news outlet having the most impact is the one getting its notifications first on user devices. The push platform needed to be able to send at least 2.5 million notifications per minute. This is a non trivial problem. If you think about the fact you need to select and read the information for each mobile device you would like to reach, that scale is demanding even if you only consider the database part, let alone the fact that we needed to reach that speed end-to-end.

  4. A need for a sophisticated topic subscription mechanism for push notifications and detailed analytics. On BBC Sports, for example, for football you need to be able to subscribe to very fine grained notifications: users select the team of interest and for each team, the type of notifications they are interested in (line up, kick-off, goals, final score). You also need to ensure that delivery of the push will only arrive once for a given device, no matter what topic combination they are subscribed to.

ProcessOne fully developed this system within three months. It included a highly scalable backend with configurable delivery speed, able to handle several millions of push notifications per minute. To operate the platform at the BBC level, ProcessOne created a management web interface, with application administration, push credentials management, user rights and detailed analytics.

Since the push notification platform ought to deliver breaking news without delay, ProcessOne implemented a fully-featured push API for communication with BBC editorial tooling. Finally, to help the BBC tech team with mobile application integration, ProcessOne prepared a set of mobile SDK for iOS and Android, and later for Amazon Push notification service and Cordova.

ProcessOne also fully managed the platform for the BBC, handling its operations and maintenance. The project launch for the BBC News was a success. It then expanded to BBC Sports. The platform covered many events, from the FIFA World Cup to the Olympics Games in London, as well as the UK Elections.

Over the first five years of the project, ProcessOne delivered a 100% uptime. The platform delivered more than 25 trillion notifications. It handled up to 150 million push notifications on a single day. This platform led to ProcessOne releasing its push notification service as a SaaS platform, under the Boxcar name.

Areas of expertise:

  • Realtime messaging
  • Push notifications
  • Mobile development
  • Platform management and hosting


  • Backend: Erlang / Ruby + Rails
  • Mobile: Objective C / Java

by Marek Foss at June 25, 2019 11:27

June 24, 2019

Ignite Realtime Blog

Openfire 4.4.0 Beta Release

@akrherz wrote:

The Ignite Realtime Community is thrilled to announce the promotion of a beta quality release of Openfire 4.4.0! Please test out this release and let us know how it goes by reporting your feedback in the Community Forums. We’d like to turn around a formal release sooner than later!

So what’s in this release you ask? The Changelog denotes many Jira issues resolved. Much of this work is thanks to @guus and @gdt! The highlights include:

  • Numerous improvements and bug fixes around Openfire’s caching. The administrative console now provides a detailed look into cache usage as well as the ability to selectively remove individual cache entries.
  • Improvements to Openfire’s stability and performance whilst in clustering mode.
  • The Admin Console will now show software versions, whenever possible, of the remotely connected client and server.
  • Java 11 should be fully supported and usable with this release. This includes using OpenJDK.
  • Plugin loading should be much more robust and the Admin Console now reports more information about the plugins loaded along with better UI interaction whilst updating plugins.
  • Openfire makes heavy usage of Apache MINA and Jetty, both of which libraries have been updated for this release.

Here’s a listing of sha1sums for the release and you can find the downloads here.

b44a621f491b33d35d138b8a9d1c041558dacf8f  openfire-4.4.0-0.2.beta.i686.rpm
ddb4871e2dbb83b10d4d6e227869f0294253d8f8  openfire-4.4.0-0.2.beta.noarch.rpm
172c9aa94353717d824bfdf13741a9be614f7e54  openfire-4.4.0-0.2.beta.x86_64.rpm
72b4ab488fb7a0116482fbb53709887b41213377  openfire_4.4.0.beta_all.deb
ceb8f315e6327d34887685b7630eba273202cf5b  openfire_4_4_0_beta_bundledJRE.exe
3e5e384d3677da30f9817a10474c75579f6b606d  openfire_4_4_0_beta_bundledJRE_x64.exe
9ff49a74679a14156c3331c7bc5ff64ed7ab8635  openfire_4_4_0_beta.dmg
4bbe3de332c44fd046ad078a7f86717611baead5  openfire_4_4_0_beta.exe
5a8cfd20a99c9c41ca6ce1a21017e36950540c36  openfire_4_4_0_beta.tar.gz
214c211b8be412c0ff75c8f59b9ce3f0bfd8d248  openfire_4_4_0_beta_x64.exe
759dc5ad17aee48cd7eecbd6b8656abd4f9f2d63  openfire_src_4_4_0_beta.tar.gz

Thanks for your interest and usage of Openfire! Our live group chat is also useful to swing by and let us know how the beta is going for you! We are always interested in folks wishing to help out with development. Please stop by and say hi!

Posts: 1

Participants: 1

Read full topic

by @akrherz daryl herzmann at June 24, 2019 18:47

June 22, 2019

Monal IM

First Mac Build With Catalyst

Monal builds and runs with catalyst. This was an initial experiment to see what the process would be like. Hilariously, as I was Googling the issues I encountered I noticed that Chris from chat secure was in the process of doing the same thing. I already know that this is going to be great for the Mac eco system. Mac users, don’t be dismayed by the very iOS look here, it starts like this and then you add more and more native Mac like components. This is the bare minimum. Even all the dark themes stuff from iOS worked perfectly on Mac. Even at the bare minimum this should perform better and have more features than the current Mac app. Targeting only one UI framework will reduce my work load by half. The good news is everything builds and runs. I disabled OMEMO for this build for a few reasons, mainly because it wouldn’t build with the SSL library I was using but them I am planning on changing the way I do crypto in ios13/Catalina so that I can ship in France so this isn’t really an issue.

by Anu at June 22, 2019 17:42

Mac Release

I have updated the Mac app in the app store. It has all of the fixes made to the iOS client as well as some ui bugs people have reported. I am focusing on catalina and catalyst now the old app will not go away, but since it will require additional work there may be delays in feature releases. Catalyst will have the same version number as the iOS. It will be a big jump .

by Anu at June 22, 2019 00:41