Planet Jabber

May 31, 2020

Aditya Borikar

Chapter 2: Modular Shift

Hello everyone,
  In the previous blog I have mentioned about some work on handshakes. I have used this week to understand Florian's newly introduced Modular Transport Architecture and update my previous progress by introducing Websocket Transport \0/.

  The modular architecture to me looks like a sophisticated approach which suggests that everything in between and beyond entering credentials and succesful authentication is a state. And each of these states are accompanied by state descriptors, serving metadata. And such states are a part of the Finite State Machine.

 This week I have been able to partially define websocket transport along with the accompanying states and descriptors.

 At the moment, I am making use of okHttp library to perform ground level websocket operations. Incase in future if we plan to replace okHttp with another websocket implementation, we would easily be able to achieve that through the help of interfaces.

 This week for me was less about coding and lots and lots of debugging. With every iteration, I was able to understand the module in a better way.

That is all for now. See you next week!

by Aditya Borikar at May 31, 2020 00:00

May 28, 2020

Anmol Chaudhary

RTT stanza and message comparision

It’s been a week and a half since I started working On Real-Time Text. Firstly I have established a framework to generate RTT message stanza and send them over the network. This includes generating relevant action elements as per requirement.

My initial goal is to get a basic real-time text model for single chat users. For that, I have planned a series of steps which are as follows:

_config.yml _config.yml

One of the important steps to achieve that is message comparison. This step will produce a difference between the previous text stored in the buffer and the new one being typed. This text difference will be translated in the form of action elements that will be sent in the element.

A correct algorithm is required to produce the right action elements. An inefficient message comparison will lead to either generation of many action elements that could lead to bandwidth issues or action elements that will make real-time texts to appear unnatural.

I found a JavaScript implementation of the XEP-0301. The message comparison method there is not efficient for our purposes. For instance, if someone makes an edit in between their text then it would first erase everything from that point and replace it with new text. This will seem unnatural to the end-user who is receiving RTT.

As planned before I was thinking in terms of either a linear scan to compare changes or some minimum edit sequence algorithm.

Fortunately, in my search, I found that Python has a standard library called difflib which offers exactly what I want for my purpose. The algorithm behind is basically a version of Longest Common Subsequence (LCS) and produces a good result that is more “human friendly”, unlike traditional LCS. Here’s a small script I ran in python inspired from this StackOverflow answer:


And the result:


Pretty neat, right!

So right now I’m looking over at implementing something like this for Dino In Vala. Instead of color-coded text to show the difference the Vala code will call methods that will generate insert and erase action elements.

May 28, 2020 00:00

Peter Saint-Andre

Crisis Investing

Exactly four years ago I wrote a post entitled "Investing for the Rest of Us", in which I discussed the permanent portfolio investing method, invented by Harry Browne. The permaent portfolio has two additional benefits that I've come to fully appreciate only this year: uncorrelated assets and forced rebalancing....

May 28, 2020 00:00

May 27, 2020 Notices

Server Software Migration

After many fine years of running Isode's M-Link server software, the admin team is currently working to migrate to the open-source Prosody server. Although we will strive to make this transition as seamless as possible, performance might suffer temporarily as we run migration scripts and the like. We apologize for any inconvenience.

May 27, 2020 00:00

May 26, 2020


Development News May 2020

This month brought new features and many improvements for Gajim plugins (checkout the new file preview)! On the other side, we had to decide which plugins to keep and which ones have to go before the 1.2 release. During this month, Anonymous Login has been re-implemented and account badges have been added. If you’re using multiple accounts with Gajim, you should be now be able to quickly recognize which account you’re chatting with.

May 26, 2020 00:00

May 24, 2020

Aditya Borikar

Chapter 1: Handshake

 It has been a week since I have been working on preliminary websocket stuff.

  The client is expected to initiate a websocket handshake by sending a HTTP GET upgrade request. During this, the client MUST include the value 'xmpp' in the list of protocols for the 'Sec-WebSocket-Protocol' header.

 If a client receives a handshake response that includes 'xmpp' in the 'Sec-WebSocket-Protocol' header, then the XMPP subprotocol webSocket connection was established successfully. In case the header is absent in the response, it means that the 'xmpp' subprotocol connection has failed and so the client must close the websocket connection immediately.

 I am able to complete this handshake procedure against a local openfire server. I have provided below the headers sent and received during handshake,

 But for this handshake to take place, we first need to discover its websocket connection endpoint for the server. For this we use RFC 7395, section 4 .

 Sending a request to "/.well-known/host-meta" at an HTTP origin that matches the XMPP service domain. For eg: If the domain is "", we should send a request at the URL "".

 Server responds to this request and provides a websocket endpoint under "urn:xmpp:alt-connections:websocket" link relation. Servers MAY expose discovery information using host-meta documents, and clients MAY use such information to determine the WebSocket endpoint for a server.

  As of now, my implementation fetches connection endpoint in case the endpoint isn't configured explicitly by the user inside `XMPPWebsocketConnectionConfiguration`. If user provides websocket URL, we directly move on to sending the HTTP upgrade request as explained earlier in this blog.

That is all for my progress as of now. Thank you for spending time and reading it!

by Aditya Borikar at May 24, 2020 00:00

May 23, 2020

Ignite Realtime Blog

Smack 4.4.0-alpha3 released

@Flow wrote:

The Ignite Realtime community is pleased to announce the release of Smack 4.4.0-alpha3.

This is scheduled to be the last alpha release of the upcoming Smack 4.4 series. In 4-6 weeks, we will create the ‘4.4’ branch in Smack’s git and prepare the first beta release. If there is a feature or API change you like to see in Smack 4.4, then you should use that merge window to get your changes into Smack.

Happy hacking!

Posts: 6

Participants: 3

Read full topic

by @Flow Florian Schmaus at May 23, 2020 17:40

May 20, 2020

Erlang Solutions

How data drives MongooseIM

To make decisions about how to steer your open source project, you need to know whether you’re on the right path or if you need to course-correct. That’s why you need to equip your project with a proper compass and barometer to help you navigate. Gathering the metrics of your project can be one of the tools that can help you gain more insight into how your project is being used. When used wisely, data can help open source maintainers understand how users are responding to new functionality. This allows you to prioritise the work you do and understand how the features are being used. You can identify less used functionalities that might not need as much support. Most importantly, data can turn suspicions and opinions into facts which help to improve your project, leading to more satisfied users.

In this blog post, we are taking a deep dive into the new MongooseIM feature that was introduced in version 3.6. Now, system metrics are gathered to analyse the trends and needs of our users, improve MongooseIM, and let us know where to focus our efforts. This blog post is devoted to explaining what the new metrics are, what they help us achieve, why we’ve done it, and how you can manage and customise them at your end.

Why do we do it?

Knowing how our product is used is critical for us to identify the core value it brings to the users. It points us in the direction in which to expand it and show us how to target our further efforts in developing it. The collected data only has statistical relevance and is automatically anonymised before it is processed any further. Each MongooseIM randomly generates a Cluster ID that is attached to the reports. A sample report showing mod_vcard backends usage from our CI builds can be found below.

load testing diagram

Such reports can show us how we approach testing different configuration scenarios. This can be contrasted with real-world metrics that are gathered.

load testing diagram

Based on these reports, we can see the frequency of different backends being used (or not used) with mod_vcard. These comparisons can tell us that the LDAP backend was not widely used for the past month; no user installation reported this configuration.
It is important to note that such reporting is not yet painting a full picture of the MongooseIM ecosystem. The metrics feature has just been introduced and is mostly showing fresh installations/upgrades. It might take some time to draw decisive conclusions from long-running deployments.

Where can you see the information gathered?

You can view all the information that is shared in two different ways. The log file system_metrics_report.json contains the most recent report that was sent. Additionally, you can configure the Tracking ID to use your own Google Analytics account and have a view of your MongooseIM status in that dashboard.

How can you configure this service?

To ensure full transparency, you will notice a log message that is generated on every MongooseIM node start (unless the metrics service is configured with the report option) to show that the functionality is enabled. We wanted to notify you that the metrics are gathered, and you have the right to withdraw consent at any time without limiting the functionality of the product. This feature is provided as a “service”. To be operational, it needs to be added to the list of services as shown below:

Example configuration

{service_mongoose_system_metrics, [
                                   {intial_report, 300000},
                                   {periodic_report, 108000000}

The metrics are first reported shortly after the system startup and later at regular intervals. These timers are configurable using the initial_report and periodic_report parameters. The default values are 5 minutes for the initial report and 3 hours for the periodic one. These reporting intervals can be changed depending on the configuration parameters. Removing the service_mongoose_system_metrics entry from the list of services will result in the service not being started. Metrics will not be collected and shared. It will generate a notification that the feature is not being used. The notification can be silenced by setting the no_report option explicitly. For more details regarding service configuration, please see Services section in our documentation.

What information are we gathering?

When introducing this feature, it is crucial for us to be fully transparent as to what information is being gathered. In general, we capture data on how MongooseIM is being used, its version and the chosen feature set. We only report the names of known modules and APIs that are part of the open source product. All additional customisations are simply counted without disclosing any specific details. The full list of information that is being gathered is listed below:

  1. MongooseIM node uptime.
  2. MongooseIM version.
  3. The number of nodes that are part of the MongooseIM cluster.
  4. Generic modules that are part of the open source project and are in use. Some modules report what database they use as a backend.
  5. Number of custom modules - without disclosing any details, we are just curious to see if there are any.
  6. Number of connected external XMPP components.
  7. List of configured REST APIs that are part of the open source project.
  8. XMPP transport mechanisms like, TCP/TLS, WebSockets or BOSH.
  9. Geographical Data - Google Analytics is providing several geographical dimensions, such as City, Country, Continent. These values are derived from the IP address the data was sent from. You can learn more about Googles Geographical Data here for more details.

How do I configure additional and private Tracking ID’s in Google Analytics?

The data is gathered and forwarded to Google Analytics. The user can add custom Google Analytics Tracking ID in the MongooseIM configuration and see all incoming events that are related to their own system metrics. For more details on how to create or sign in to the Google Analytics account, please see Get Started with Analytics.
The Tracking ID is a property identification code that all collected data is associated with. It determines the destination where the collected data is sent. To create a new Tracking ID, please follow the steps below:

  1. Go to the Admin tab of your user dashboard.
  2. Create a new account with + Create Account.
  3. Add new property with + Create Property.
  4. Within the new property go to Tracking Info > Tracking Code.
  5. The Tracking ID can be found in the top left corner of the section and has the following format UA-XXXX-Y.

Example configuration

A new Tracking ID can be added to the list of options as follows:

{service_mongoose_system_metrics, [
                                   {intial_report, 300000},
                                   {periodic_report, 108000000},
                                   {tracking_id, UA-XXXX-Y}


Getting equipped with knowledge for the journey of your open source project might be a crucial factor to develop a successful product. Collecting metrics about your software can help you plan your work, measure quality and gain more insight on how your project is being used. If you’d like to learn more about how MongooseIM makes scalable, customisable instant messaging easy head to our MongooseIM page, or get in touch.

For more information and MongooseIM System Metrics Privacy Policy, please see our documentation page.

You may also be interested in:

Our new online training

How MongooseIM is improving push notifications

Which new companies are using Erlang and Elixir

Is your Instant Messaging platform GDPR complaint?

May 20, 2020 11:54

Jérôme Poisson

SàT progress note 2020-W21

Hello everybody,

during the last few weeks, I've been focusing on Libervia (web): I've been working on the management of dynamism, or in other words the integration of JavaScript and browser side Python with the Libervia web framework.

If you're wondering what I mean by "browser side Python", let me explain briefly some history of Libervia: the former version of this web frontend was a single page application made with Pyjamas, a framework more a less similar to GWT but with Python instead of Java. The main reasons of this choice was to avoid constantly moving from 2 different programming platforms (Python and JavaScript), to factorise code with other frontends, and to avoid the JavaScript ecosystem which is constantly moving (resulting in lot of time spent in following the evolutions, learning new frameworks, rewriting code, etc.).

Pyjamas was made of 2 main parts: a Python to JavaScript transpiler, and a set of libraries to write a web site in a way similar to a desktop application. This was working reasonably well, and once past the initial big download, the application was working nicely. We could indeed factorise code with other frontends, and save time and maintenance efforts.

With time, we realised that hiding the abstraction of the web development to make it look like desktop was not so great: since the beginning of Libervia, the web ecosystem had improved greatly (HTML 5 and CSS things like flexbox notably), and it was getting hard to use the novelties. The application was not responsive and unusable on mobile, while phone was getting the main platform for many people.

In addition, 2 major issues were resulting in a dead end for Pyjamas: first a hijack of the project (not just hostile fork, but true hijack: the official website has been redirected to the fork named pyjs without the consent of the main contributor of Pyjamas, and the mailing list has been redirected without the consent of its subscribers), and second Pyjamas was stuck with Python 2, and a Python 3 port would mean a nearly full rewrite.

So we decided to move away, and the result was Libervia Pages, i.e. the framework made to integrate XMPP, Python, and web. For SàT 0.7 the first goal was to have a static or nearly static framework, with minimal JavaScript, and to implement dynamic part for 0.8.

The decision was to keep Python in the browser, for the same reason that initially lead to Pyjamas, but this time with the possibility to change the "engine", i.e. the software allowing to do Python in the browser. So we keep the door open to use only JavaScript if in the future we decide to move to something like Vue.js or React.

We have been carefully checking the various options, and our favorite candidates were Brython and Transcrypt.

Transcrypt is a Python to JavaScript transpiler, pretty similar to what was doing the transpiler of Pyjamas. It has the advantage of staying close to JavaScript, keeping its speed, and has a system to activate/deactivate Python compatibility features depending on the needs (better compatibility may mean lower performances).

Brython on the other hand is doing the transpilation in the browser, it is like having a Python interpreter in the browser. Its has some decisive (for us) advantages: full Python compatibility, and the possibility to dynamically convert Python to JS. The Python compatibility is essential to factorise the code with other frontends, and the ability to convert Python to JS open the way for future use (like sharing code during a chat, e.g. for a school or scientific use). I've been following the Brython community for years, it is really friendly and dynamic, and the few issues I've reported online were addressed quickly.

So Brython has been chosen as the main way to do dynamic code in the Libervia web framework, but it is possible to switch to something else. To use it, it is as simple as writing some Python in a file in a _browser directory of a page ; Libervia will take care of installing Brython, copying and loading the script.

As an example, here is how you would show an alert if somebody click on an element with author class:

from browser import bind,alert

@bind(".author", "click")
def click(ev):
    alert("click on an author")

As we want to have dynamism used progressively (i.e. the page works without JavaScript, but enhancement happen if JavaScript is activated), it's really straightforward to work this way, while it is still possible to do more complex code for fully dynamic pages (like it will be the case for the chat).

Beside Python, JavaScript ecosystem been integrated through the use of either yarn or npm (whichever is present on the system). A common JSON file is used to indicate dependencies (using the syntax of package.json well known by frontend developers), and potentially how to generate corresponding Brython module. Sass has been integrated too.

I've also worked on themes, but I don't want to make this blog post too long to write and read, so I'll talk about that next time.

by goffi at May 20, 2020 10:23

Anmol Chaudhary

GSoC 2020 begins - Introduction to RTT

Hello there!

I’m Anmol, a pre-final year computer science student from India. I’ve always been intrigued by chat clients (read: I interact with people a lot via text) which explains my affinity towards working on Dino under XMPP Standards Foundation as a part of Google Summer of Code.

For my project this summer I will be implementing Real Time Texting in Dino as per XEP-0301 guidelines.

Real time texting (RTT) allows users to see what their peer is typing live before they even send the message. This will allow for textual conversations to be much more fluid and engaging than traditional texting. Audio and video calls also achieve fluid communication but they lack the discretion of texting. RTT aims to bring the best of both worlds; discretion of texting and fluidity of audio/video calls. RTT can also be beneficial for next-gen emergency services or customer support, as the respondent could figure out early what the other person wants to convey thus enabling quick actions.

Although the coding period starts from June 1, I have already started with work 2 weeks prior as this is an unusual year due to pandemic with an uncertain university schedule.

I look forward to an exciting summer working with the XSF community.

May 20, 2020 00:00

May 19, 2020

Ignite Realtime Blog

Openfire 4.5.2 is Released

@akrherz wrote:

The Ignite Realtime Community is happy to announce the availability of Openfire version 4.5.2. This release resolves a number of bugs including a long standing issue of the Japanese Translation (OF-1966) not being available on the admin console! The release signifies our effort to stabilize a 4.5 series release while developing the soon to come 4.6.0.

You can find download artifacts available with the followng sha1sum values:

5e4011517d2d445a3816cc772c02ade5ed42bdde  openfire-4.5.2-1.i686.rpm
726b9f7f49876684ab7d8afd9c268f6d1ed59606  openfire-4.5.2-1.noarch.rpm
fedfefe709dde35042e1c73fc2be959e87fb499a  openfire-4.5.2-1.x86_64.rpm
b03cb01d937e2c499d585e2b9438a1fee7d864d4  openfire_4.5.2_all.deb
90b75516257bac311f7fad4e3bd4061d57757135  openfire_4_5_2_bundledJRE.exe
d77b515a0c272844c1a4d41dbf3a3c37dd9fd3f9  openfire_4_5_2_bundledJRE_x64.exe
20b0ee0839c7563c2bf9729bbb975816d8189588  openfire_4_5_2.dmg
4c5b7be4cc80fad95db404e71b5e50d4f36ef6a2  openfire_4_5_2.exe
38bcf3b4ac19effa30187047535b7d9400140aaa  openfire_4_5_2.tar.gz
e793882c17ba9b3b4ba1469e17de09e0c5bef9ee  openfire_4_5_2_x64.exe
654884e8ebe2ffe111d28f8e3595dbcc3c84d7d7  openfire_src_4_5_2.tar.gz

For your curiosity, here’s an accounting of the number of artifact downloads for the 4.5.1 release of Openfire made back on 31 January.

Artifact Count
openfire-4.5.1-1.i686.rpm 866
openfire-4.5.1-1.noarch.rpm 1688
openfire-4.5.1-1.x86_64.rpm 5581
openfire_4.5.1_all.deb 12024
openfire_4_5_1.dmg 1717
openfire_4_5_1.exe 5954
openfire_4_5_1.tar.gz 3855 1463
openfire_4_5_1_bundledJRE.exe 1725
openfire_4_5_1_bundledJRE_x64.exe 11227
openfire_4_5_1_x64.exe 15170
openfire_src_4_5_1.tar.gz 138 160
Total 61568

As always, a big thanks goes to @guus for his heroic development efforts of Openfire. Please give this a release a try and stop by our support groupchat to let us know how it goes. Hopefully a 4.6.0 beta release is not too far away, so if you are in a position to test master branch / nightly builds, please consider doing so!

For other release announcements and news follow us on Twitter

Posts: 1

Participants: 1

Read full topic

by @akrherz daryl herzmann at May 19, 2020 10:51

May 16, 2020

Aditya Borikar

Chapter 0: Introduction

 Google Summer of Code is a great opportunity for me to engage with open source communities. This is my introductory blog and an amateur attempt at blogging.

 Thanks for taking efforts, to reach out here and so I am obliged to tell a bit more about my aspirations.

 Hi, My name is Aditya, a candidate for GSOC 2020 through XMPP Standards Foundation. The opinions expressed here are mine alone and are subject to change.
 I am mesmerized by the impact social networking has on lives. I consider that, development of a networking platform revolves around two crucial and fundamental concepts:
 a) Transmission of secure data across the network.
 b) Ability to generate data which is interpretable at other nodes.

 Transmission of secure data would dive more into cryptography. I am more inclined towards generating interpretable data which invokes the need for a set of protocols, to be followed by each of the nodes on a network. This motivates me to get involved with the XMPP community. Moreover, working on Smack- a client library for XMPP would give me the freedom to focus specifically on the set of protocols and be less bothered about user interfaces.

 My GSoC proposal is about adding WebSocket support to Smack. My past experience with the Ignite Realtime Community has been intellectually rewarding and am happy to keep my part through this year's GSoC program.

 Looking forward to an amazing summer!

Learn more about my project here.

by Aditya Borikar at May 16, 2020 00:00

May 12, 2020


New Anti-Spam Measures

Some days ago, we have rolled out a new anti-spam measure on our public XMPP server. Accounts registered from a malware infected computer or through an open proxy (unfortunately this also includes Tor exit nodes) are flagged by default and need a manual approval from the server admins to become fully usable.

Registrations on the server already were limited to a small number of new accounts per IP address per hour, to prevent large amounts of automated registrations. However, spammers circumvented that for some time already by using open proxy servers on the Internet to create thousands of accounts.

Starting last week, we are putting accounts that use open proxy servers into quarantine, where they are limited to contacting the server support and to kindly ask to be unblocked. Users affected by the quarantine will receive a message with a link to the support chat as well as a link explaining why their IP address was blocked:

Message to quarantined user

Trying to contact anyone else will result in errors shown to the user:

Error when contacting other users

Behind the scenes, we are using a Real time Blackhole List to identify accounts for the quarantine, based on this prosody setup. We are aware that it will affect legitimate anonymisation proxy users, and we are very sorry about that. There might be only a dozen of actual for-hire spammers on XMPP, but their impact on our ecosystem is staggering.

As the server is operated by volunteers, we do not have a 24/7 support team, so please be patient when requesting an unblocking.

May 12, 2020 16:20

May 11, 2020

Ignite Realtime Blog

Monitoring Openfire plugin 2.0.1 released

@wroot wrote:

The Ignite Realtime community is happy to announce the release of version 2.0.1 of the Monitoring plugin for Openfire!

This update fixes an error if search text contains special characters, removes false advertisement of free text search in personal archives and improves MAM IQ results.

Your instance of Openfire should automatically display the availability of the update. Alternatively, you can download the new release of the plugin at the Monitoring plugin’s archive page

For other release announcements and news follow us on Twitter

Posts: 1

Participants: 1

Read full topic

by @wroot wroot at May 11, 2020 18:55

Aditya Borikar

Welcome to my official GSoC log!

Hi there, I just created this Github page !

Please excuse my bad web-dev skills ಥ_ಥ

by Aditya Borikar at May 11, 2020 00:00

May 10, 2020

Arnaud Joset

Update Errol: the XMPP Automatic file sender

Errol is a file sender that can be used to watch a directory and automatically transfers the new files (or modified ones) with XMPP.

You can find the previous description here.

I recently updated it to V2.0.1. This articles describes the changes since last article.


  • Replaced all the yield from syntax to async/await syntax for asyncio calls
  • Added some options to enable or not the muc/pubsub features. If your XMPP account does not have a proper pubsub service or if you don't want to advertise your file transfer, these functionalities are not mandatory anymore.
  • Moving from aionotify to watchdog. aionotify was not actively developed since 2 years. Even if is not asynchronous, watchdog can be used with hachiko.

Errol should now be usable on Linux, Windows, Mac OS X and FreeBSD because watchdog supports all these operating systems. Note: only Linux has been tested so far.

I also performed small improvements, refactoring and bug fixes.

Getting started

The list of dependencies has been updated but remains quite small.


You can easily install errol with pip.

$ pip install errol

On Archlinux, a PKGBUILD is available in AUR.


The complete list of options is available in the template config file.

$ cat config.example.ini

  • jid : the jabber account
  • password: the xmpp password
  • pubsub: the pubsub server (publish activity)
  • room: the MUC (chatroom) where errol display information.
  • presence_file: a writable file used to keep track of presences. I use it in a Django Application. 1

The files will be sent by and received by . The nicks are the usernames used on the MUC.

Use it

Errol should now be usable with only a simple XMPP account and a directory to watch. If you are interested by the Pubsub feature, don't hesitate to read the previous article. It contains a section to setup a pubsub node, configure it and access it with several tools.


  1. When receiver is online, the file contains '1' and '0' otherwise. It is not super clean but I did not wanted to bring XMPP features in a Django app.

by Arnaud at May 10, 2020 15:00

May 07, 2020


Gajim 1.2.0 Beta

It has been almost a year since the release of Gajim 1.1.3. A year of developing new features, cleaning up old code, and bug fixing. This month it is finally the time for a first beta release of Gajim 1.2. Highlights are (amongst others): improved group chat system, completely rewritten network code, and a new account creation assistant. But there is much more to discover. If you have suggestions on how this Beta can be improved, please let us know. Your feedback is welcome.

May 07, 2020 00:00

May 06, 2020

The XMPP Standards Foundation

Collaboration over the Internet! - 7 May 2020


Welcome to the XMPP newsletter covering the month of April 2020.

We are always happy about contributors. Just join the discussion in our Comm-Team group chat (MUC) and help us sustain this as a community effort. The drafting process for each newsletter is fully documented. Furthermore, we started drafting each new version in the XSF Github repository - feel free to add information by yourself.

Newsletter translations

The translations of the XMPP Newsletter will be released here:

XMPP Standards Foundation

The XSF is renewing its sponsorship for 2020. Many thanks to everyone supporting and sponsoring us in 2019. We would be happy if your organization would also consider sponsoring in 2020. If your organization considers sponsoring for the first time, our mission may interest you as well.

Alexander Gnauck published the Membership Applications Q2 2020. Applications are welcome!


Pasis, maintainer of libstrophe and contributor to profanity, wrote about using the XML console in profanity for debugging.

Jan Cieśla from MongooseIM wrote a blog post about how they drive their project by the metrics.

Can you believe it? Zoom uses XMPP for its chat - cool! Vulnerability - not cool.

MattJ (Prosody developer) mentioned that, according to Debian popcon statistics, the Prosody installations have doubled since march.

Software releases

Kaidan 0.5.0 - Bam! Check out their new onboarding!

Let's sum it up like this: Remove OTR + Rework conference and contact details + Show PDF previews + Add title for audio files = Pix-Art Messenger 2.3.5

Four letters for Windows 10 Users: UWPX 0.25.0 is online with Windows10X support and a push server. So give it a try!

Monal continues the fight on the iOS front: included in the upcoming beta are support for geo-location messages, TLS ALPN support and improvements on OpenFire push notifications as well as many fixes with smack.

Wow - no late April joke - Conversations released version 2.8.0 adding audio and video calls! The German IT magazine wrote an article about the new A/V-Feature.


Guus der Kinderen, from the Ignite Realtime Foundation Board, wrote a short article on how to setup a STUN and TURN service in Openfire for audio and video calls. The improvements for push notifications on iOS (see the post above for Monal) found their way into the Push Notification Openfire plugin 0.7.0.

Clients and applications

The maintainer of libstrophe, Pasis, and contributor to Profanity, created a tool named xmppconsole which sends raw XMPP stanzas over an XMPP connection and displays the XMPP stream. Main purpose is to study XEPs and debug servers implementation. The tool is under development. The final version will support both GTK UI and ncurses UI. In their blog, they also explained how to easier contribute commits to their repository, read on.

Dino now features Last Message Correction for all the typos you made and the regrets you have. And also voice handling in moderated groups

Gajim Development News April 2020: Multi-account handling improvements and polishing for the release of Gajim 1.2. One year after the last release, a beta for the upcoming version is just around the corner.

Services updated their servers from prosody 0.11 to prosody-trunk. Read more about the changes here. Unfortunately with a first outage :(

On April 25th, was launched into public beta. It offers free monitoring-as-a-service for federated XMPP domains, checking connectivity via c2s and s2s, as well as optionally in-band registration and federated XMPP pings. Application details and more information are available on the website.

Process One released ejabberd 20.04. Highlight: Support for XEP-0215 External Service Discovery which improves support for audio and video calls. The mod_stun_disco module allows XMPP clients to discover STUN/TURN services.


StropheJS, a XMPP library for JavaScript, has been released in version 1.3.5 with bugfixes and removal of support for SASL DIGEST-MD5 auth.

Extensions and specifications


  • Version 1.18.0 of XEP-0060 (Publish-Subscribe)

    • Properly specifiy that an empty is invalid on publish. (jsc)
  • Version 0.4 of XEP-0333 (Chat Markers)

    • Add notes about usage within MUCs. (mw)
  • Version 0.4.0 of XEP-0389 (Extensible In-Band Registration)

    • Add OOB challenge type.
    • Add IQ query for flows.
    • Add a glossary.
    • Make challenge listings more consistent.
    • Cleanup and expand the registrar considerations section.
    • Clarifications and typo fixes throughout the text. (ssw)


The XMPP Extensions Editor has received proposals for new XEPs.



  • Version 0.1.0 of XEP-0435 (Reminders)
    • This specification provides a way to set up reminders.
    • Accepted by vote of Council on 2020-03-04. (XEP Editor (jsc))


  • Version 1.0.0 of XEP-0402 (PEP Native Bookmarks)
    • Abstract: This specification defines a syntax and storage profile for keeping a list of chatroom bookmarks on the server.
    • Changelog: Advanced to Draft per Council vote from 2020-03-04. (XEP Editor (jsc))

Thanks all!

This XMPP Newsletter is produced collaboratively by the community.

Thanks to Aleja, emus, horazont, jcbrand, mdosch, pep., pmaziere, Sven, wurstsalat3000 for their help in creating it!

Please share the news on "social networks":


This newsletter is published under the CC BY-SA license

by emus at May 06, 2020 22:00

May 01, 2020

Monal IM

4.6 Mac and iOS betas

There are new betas for Mac and iOs 4.6. This has the fixed parser that is faster, uses less battery, memory and is more compatible.

by Anu at May 01, 2020 14:38

April 28, 2020

Ignite Realtime Blog

Push Notification Openfire plugin 0.7.0 released

@wroot wrote:

The Ignite Realtime community is happy to announce the release of version 0.7.0 of the Push Notification plugin for Openfire!

This update provides better behavior on iOS devices by letting messages to wake up a device and limiting the rate of push notifications.

Your instance of Openfire should automatically display the availability of the plugin in the next few hours. Alternatively, you can download the new release of the plugin at the Push Notification plugin archive page

For other release announcements and news follow us on Twitter

Posts: 1

Participants: 1

Read full topic

by @wroot wroot at April 28, 2020 18:56


Development News April 2020

This month’s development revolved around polishing Gajim for the upcoming Beta of Gajim 1.2. Almost a year after the last release, a fresh beta is just around the corner. During April, we also implemented multi-account improvements and fixed some nasty bugs.

April 28, 2020 00:00

April 27, 2020


Multi-day Message Archive Outage

The day after the upgrade to prosody-trunk, there was an interruption in the database connection to the server’s message archive. Due to this, no messages were stored in the users’ XEP-0313: MAM storage. For users who have more than one client, this will lead to incomplete synchronization: some messages will not arrive on all devices, and it will not be possible to synchronize the history for the past four days to newly installed devices. We are very sorry for the inconvenience.

The issue happened on Friday, 2020-04-23, at 07:38 UTC, and continued until today, 2020-04-27, 16:29 UTC. Due to lack of automatic monitoring, it was not discovered sooner. We are currently investigating the root cause (and also monitoring the database connection very closely).

As the fallback “offline storage” mechanism was not affected, users should receive all messages on at least one of their devices.

April 27, 2020 16:37

April 26, 2020

Ignite Realtime Blog

Preparing Openfire for Audio/Video calls with Conversations

@guus wrote:

Later this week, the popular Android client Conversations will have an exciting new release that will allow you to make voice and video calls.

For this to work well with your instance of Openfire, it is recommended to make use of a STUN and TURN service. I’ve personally experimented with coturn, which I’ve found easy to use.

After you’ve set up the STUN and TURN service, you’ll need to configure Openfire to expose the availability of this new service to your users. You can do this easily with the External Service Discovery plugin for Openfire.

After you install the plugin, you can add your TURN and STUN services to its configuration, as shown below. This will allow clients to discover the availability of these services!


Take care to read up on the authentication mechanisms that are available in your TURN server, to prevent unrelated third parties from making use of your bandwidth.

That’s all to it!

For other release announcements and news follow us on Twitter

Posts: 9

Participants: 6

Read full topic

by @guus Guus der Kinderen at April 26, 2020 19:27

April 23, 2020


New prosody on

The software on has been upgraded from version 0.11 to prosody-trunk. While the new version is still considered as experimental, it provides many under-the-hood improvements that make the trade-off worthwhile. If you notice any issues, please report in the yaxim room (webchat).

The primary reason why this change became necessary is that the previous version of mod_push_appserver (the XEP-0357: Push server for yaxim users) was using synchronous calls to Google FCM to wake up yaxim. This blocked all message processing on for a brief moment, or for many seconds when there were issues with the network connection to Google’s servers. As asynchronous requests are only sufficiently supported in prosody-trunk, it was required to drop support for older prosody versions in mod_push_appserver, which has happened with the 4.0 release.

On top of that, with the new version it is also possible to further optimize mobile battery usage (mod_cache_c2s_caps) and to upgrade the service to the Lua 5.3 runtime with better server-side memory efficiency (it is currently running on 5.2). These changes will be implemented in the coming days / weeks when the operation has proved as stable otherwise.

April 23, 2020 12:52

April 19, 2020


New mailing list

I would like to announce that thanks to toogley we have a new mailing list. You can register on

The list is hosted by datenkollektiv.

April 19, 2020 20:50