• Pl chevron_right

    ProcessOne: ejabberd 22.05 / PlanetJabber · 7 days ago - 11:53 · 12 minutes

A new ejabberd release is finally here! ejabberd 22.05 includes five months of work, 200 commits, including many improvements (MQTT, MUC, PubSub, …) and bug fixes.

  • Improved MQTT, MUC, and ConverseJS integration
  • New installers and container
  • Support Erlang/OTP 25

When upgrading from the previous version please notice: there are minor changes in SQL schemas, the included rebar and rebar3 binaries require Erlang/OTP 22 or higher, and make rel uses different paths. There are no breaking changes in configuration, and only one change in commands API.

A more detailed explanation of those topics and other features:

New Indexes in SQL for MUC

Two new indexes were added to optimize MUC. Those indexes can be added in the database before upgrading to 22.05, that will not affect older versions.

To update an existing database, depending on the schema used to create it:

  • MySQL ( mysql.sql or ):
CREATE INDEX i_muc_room_host_created_at ON muc_room(host(75), created_at);
CREATE INDEX i_muc_room_subscribers_jid USING BTREE ON muc_room_subscribers(jid);
  • PostgreSQL ( pg.sql or ):
CREATE INDEX i_muc_room_host_created_at ON muc_room USING btree (host, created_at);
CREATE INDEX i_muc_room_subscribers_jid ON muc_room_subscribers USING btree (jid);
  • SQLite ( lite.sql or ):
CREATE INDEX i_muc_room_host_created_at ON muc_room (host, created_at);
CREATE INDEX i_muc_room_subscribers_jid ON muc_room_subscribers(jid);
  • MS SQL ( mssql.sql ):
CREATE INDEX [muc_room_host_created_at] ON [muc_registered] (host, nick)
CREATE INDEX [muc_room_subscribers_jid] ON [muc_room_subscribers] (jid);

Fixes in PostgreSQL New Schema

If you moved your PostgreSQL database from old to new schema using mod_admin_update_sql or the update_sql API command, be aware that those methods forgot to perform some updates.

To fix an existing PostgreSQL database schema, apply those changes manually:

ALTER TABLE archive DROP CONSTRAINT i_archive_sh_peer;
ALTER TABLE archive DROP CONSTRAINT i_archive_sh_bare_peer;
CREATE INDEX i_archive_sh_username_peer ON archive USING btree (server_host, username, peer);
CREATE INDEX i_archive_sh_username_bare_peer ON archive USING btree (server_host, username, bare_peer);

DROP TABLE carboncopy;

ALTER TABLE push_session DROP CONSTRAINT i_push_session_susn;
CREATE UNIQUE INDEX i_push_session_susn ON push_session USING btree (server_host, username, service, node);

ALTER TABLE mix_pam DROP CONSTRAINT i_mix_pam_us;
CREATE UNIQUE INDEX i_mix_pam ON mix_pam (username, server_host, channel, service);
CREATE INDEX i_mix_pam_us ON mix_pam (username, server_host);

CREATE UNIQUE INDEX i_route ON route USING btree (domain, server_host, node, pid);

ALTER TABLE mqtt_pub DROP CONSTRAINT i_mqtt_topic;
CREATE UNIQUE INDEX i_mqtt_topic_server ON mqtt_pub (topic, server_host);

API Changes

The oauth_revoke_token API command has changed its returned result. Check oauth_revoke_token documentation.

API Batch Alternatives

If you use the command delete_old_messages periodically and noticed it can bring your system to an undesirable state with high CPU and memory consumption…

Now you can use delete_old_messages_batch , which performs the operation in batches, by setting the number of messages to delete per batch and the desired rate of messages to delete per minute.

Two companion commands are added: delete_old_messages_status to check the status of the batch operation, and abort_delete_old_messages to abort the batch process.

There are also new equivalent commands to delete old MAM messages.

Erlang/OTP and Elixir

From now, Erlang/OTP 25 is supported. As that’s a brand new version, for stable deployments you may prefer to use 24.3 or other lower version.

Notice that ejabberd can be compiled with Erlang as old as 19.3, but the rebar and rebar3 binaries included with ejabberd 22.05 require at least Erlang 22. This means that, to compile ejabberd 22.05 with those tools using an Erlang version between 19.3 and 21.3, you should get yourself a compatible rebar/rebar3 binary. If your operating system doesn’t provide a suitable one, you can download the old ones: rebar from ejabberd 21.12 and rebar3 from ejabberd 21.12 .

Regarding Elixir supported versions:

  • Elixir 1.4 or higher is supported for compilation, but:
  • Elixir 1.10 is required to build OTP releases ( make rel and make dev )
  • Elixir 1.11 is required to run make relive
  • Elixir lower than 1.11.4 requires Erlang lower than 24 to build OTP releases


mod_conversejs was introduced in ejabberd 21.12 to serve a simple page for the Converse.js XMPP web browser client.

Several improvements in mod_conversejs now allow a simpler configuration, and more customization at the same time:

  • The options now support the @HOST@ keyword
  • The options now support auto , which uses local or remote Converse files
  • The Converse’s auth and register options are set based on ejabberd’s configuration
  • default_domain option now has @HOST@ as default value, not the first defined vhost
  • conversejs_options : New option to setup additional options for Converse
  • conversejs_resources : New option to serve converse.js files (no need to setup an additional web server)

For example, if you downloaded Converse, now you can setup WebSocket, mod_conversejs , and serve Converse without additional web server, in an encrypted port, as simple as:

    port: 443
    module: ejabberd_http
    tls: true
      /websocket: ejabberd_http_ws
      /conversejs: mod_conversejs

    conversejs_resources: "/home/ejabberd/conversejs-9.0.0/package/dist"

With that configuration, Converse is available in https://localhost/conversejs

More details in the mod_conversejs documentation .

New Installers

For many years, the release of a new ejabberd source code package was accompanied with binary installers, built using InstallBuilder and CEAN, and available in the ProcessOne Downloads page.

Since this ejabberd 22.05, there are new installers that use a completely different build method:

  • they are built using the tools provided in PR 3781
  • they use the most recent stable dependencies
  • they are available for linux/amd64 and linux/arm64 architectures
  • they are built automatically using the Installers Workflow
  • for stable releases, they are available for download in the ejabberd GitHub Releases
  • they are built also for every commit in master branch, and available for download in the results of Installers Workflow
  • if the installer is ran by root, it installs in /opt/ejabberd* and setups systemd service
  • if ran by a regular user, it asks installation path

However, compared to the old installers, those new installers:

  • do not ask for domain: now you must edit ejabberd.yml and set the hosts option
  • do not register the first Jabber account and grant admin rights: you must do it yourself

Please give those new installers a try, and comment any problem, improvement or ideas.

New Container Image

In addition to the ejabberd/ecs Docker container image published in Docker Hub , there is a new container image published in ejabberd GitHub Packages .

Its usage is similar to the ejabberd/ecs image, with some benefits and changes worth noting:

  • it’s available for linux/amd64 and linux/arm64 architectures
  • it’s built also for master branch, in addition to the stable ejabberd releases
  • it includes less customizations to the base ejabberd compared to ejabberd/ecs
  • it stores data in /opt/ejabberd/ instead of /home/ejabberd/

See its documentation in CONTAINER .

If you used previous images from that GitHub Packages registry please note: until now they were identical to the ones in Docker Hub, but the new 22.05 image is slightly different: it stores data in /opt/ejabberd/ instead of /home/ejabberd/ . You can update the paths to the container volumes in this new image, or switch to Docker Hub to continue using the old same images.

Source Code Package

Until now, the source code package available in the ProcessOne Downloads page was prepared manually together with the binary installers. Now all this is automated in GitHub, and the new source code package is simply the same one available in GitHub Tags .

The differences are:

  • instead of tgz it’s now named tar.gz
  • it contains the .gitignore file
  • it lacks the configure and aclocal.m4 files

The compilation instructions are slightly improved and moved to a separate file:

New make relive

This new make relive is similar to ejabberdctl live , but without requiring to install or build an OTP release: compile and start ejabberd immediately!

Quickly put:

  • Prepare it with: ./ && ./configure --with-rebar=./rebar3 && make
  • Or use this if you installed Elixir: ./ && ./configure --with-rebar=mix && make
  • Start without installing (it recompiles when necessary): make relive
  • It stores config, database and logs in _build/relive/
  • There you can find the well-known script: _build/relive/ejabberdctl
  • In that erlang shell, recompile source code and reload at runtime: ejabberd_admin:update().

Please note, when make relive uses Elixir’s Mix instead of Rebar3, it requires Elixir 1.11.0 or higher.

New GitHub Workflows

As you may notice while reading these release notes, there are new github workflows to build and publish the new installers and the container images, in addition to the Common Tests suite.

The last added workflow is Runtime. The Runtime workflow ensures that ejabberd compiles with Erlang/OTP 19.3 up to 25, using rebar, rebar3 and several Elixir versions. It also checks an OTP release can be built, started, register an account, and stop ejabberd.

See its source code runtime.yml and its results .

If you have troubles compiling ejabberd, check if those results reproduce your problem, and also see the steps used to compile and start ejabberd using Ubuntu.

Translations Updates

The German, Portuguese, Portuguese (Brazil), Spanish and Catalan translations are updated and completed. The French translation was greatly improved and updated too.

Documentation Improvements

Some sections in the ejabberd Documentation are improved:



  • C2S: Don’t expect that socket will be available in c2s_terminated hook
  • Event handling process hook tracing
  • Guard against erlang:system_info(logical_processors) not always returning a number
  • domain_balancing : Allow for specifying type only, without specifying component_number


  • Add TLS certificate authentication for MQTT connections
  • Fix login when generating client id, keep connection record ( #3593 )
  • Pass property name as expected in mqtt_codec (fixes login using MQTT 5)
  • Support MQTT subscriptions spread over the cluster ( #3750 )


  • Attach meta field with real jid to mucsub subscription events
  • Handle user removal
  • Stop empty MUC rooms 30 seconds after creation
  • default_room_options : Update options configurable
  • subscribe_room_many_max_users : New option in mod_muc_admin


  • Improved options to support @HOST@ and auto values
  • Set auth and register options based on ejabberd configuration
  • conversejs_options : New option
  • conversejs_resources : New option


  • mod_pubsub : Allow for limiting item_expire value
  • mod_pubsub : Unsubscribe JID on whitelist removal
  • node_pep : Add config-node and multi-items features ( #3714 )


  • Improve compatibility with various db engine versions
  • Sync old-to-new schema script with reality ( #3790 )
  • Slight improvement in MSSQL testing support, but not yet complete

Other Modules

  • auth_jwt : Checking if an user is active in SM for a JWT authenticated user ( #3795 )
  • mod_configure : Implement Get List of Registered/Online Users from XEP-0133
  • mod_host_meta : New module to serve host-meta files, see XEP-0156
  • mod_mam : Store all mucsub notifications not only message notifications
  • mod_ping : Delete ping timer if resource is gone after the ping has been sent
  • mod_ping : Don’t send ping if resource is gone
  • mod_push : Fix notifications for pending sessions (XEP-0198)
  • mod_push : Keep push session ID on session resume
  • mod_shared_roster : Adjust special group cache size
  • mod_shared_roster : Normalize JID on unset_presence ( #3752 )
  • mod_stun_disco : Fix parsing of IPv6 listeners


  • autoconf: Supported from 2.59 to the new 2.71
  • fast_tls: Update to 1.1.14 to support OpenSSL 3
  • jiffy: Update to 1.1.1 to support Erlang/OTP 25.0-rc1
  • luerl: Update to 1.0.0, now available in
  • lager: This dependency is used only when Erlang is older than 22
  • rebar2: Updated binary to work from Erlang/OTP 22 to 25
  • rebar3: Updated binary to work from Erlang/OTP 22 to 25
  • make update : Fix when used with rebar 3.18


  • mix release : Copy include/ files for ejabberd, deps and otp, in mix.exs
  • rebar3 release : Fix ERTS path in ejabberdctl
  • : Set default ejabberd version number when not using git
  • mix.exs : Move some dependencies as optional
  • mix.exs : No need to use Distillery, Elixir has built-in support for OTP releases ( #3788 )
  • tools/make-binaries : New script for building Linux binaries
  • tools/make-installers : New script for building command line installers


  • New make relive similar to ejabberdctl live without installing
  • ejabberdctl : Fix some warnings detected by ShellCheck
  • ejabberdctl : Mention in the help: etop , ping and started / stopped
  • make rel : Switch to paths: conf/ , database/ , logs/
  • mix.exs : Add -boot and -boot_var in ejabberdctl instead of adding vm.args
  • tools/ : Fix some warnings detected by ShellCheck


  • Accept more types of ejabberdctl commands arguments as JSON-encoded
  • delete_old_mam_messages_batch : New command with rate limit
  • delete_old_messages_batch : New command with rate limit
  • get_room_occupants_number : Don’t request the whole MUC room state ( #3684 , #1964 )
  • get_vcard : Add support for MUC room vCard
  • oauth_revoke_token : Add support to work with all backends
  • room_unused_* : Optimize commands in SQL by reusing created_at
  • rooms_unused_... : Let get_all_rooms handle global argument ( #3726 )
  • stop|restart : Terminate ejabberd_sm before everything else to ensure sessions closing ( #3641 )
  • subscribe_room_many : New command


  • Updated Catalan
  • Updated French
  • Updated German
  • Updated Portuguese
  • Updated Portuguese (Brazil)
  • Updated Spanish


  • CI: Publish CT logs and Cover on failure to an external GH Pages repo
  • CI: Test shell scripts using ShellCheck ( #3738 )
  • Container: New workflow to build and publish containers
  • Installers: Add job to create draft release
  • Installers: New workflow to build binary packages
  • Runtime: New workflow to test compilation, rel, starting and ejabberdctl

Full Changelog

All changes between 21.12 and 22.05

ejabberd 22.05 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub .

The source package and installers are now available in GitHub Release / Tags . To check the *.asc signature files, see How to verify ProcessOne downloads integrity .

The Docker image is in Docker Hub , and a new Container image at GitHub Packages .

If you suspect that you’ve found a bug, please search or fill a bug report on GitHub Issues .

The post ejabberd 22.05 first appeared on ProcessOne .
  • Pl chevron_right

    JMP: Togethr: Social / PlanetJabber · Wednesday, 11 May - 20:45 · 2 minutes

Last week we launched a sister product from the same team that brings you JMP: Togethr .  Why are we launching a second product?  Why now?  What does this have to do with the mission of JMP in particular, or the Sopranica project in general?

Togethr is a managed hosting platform for small Fediverse instances.  It is powered by the ActivityPub protocol that powers Mastodon, PeerTube, and so many others.  While there are several social networking solutions that build on XMPP (just like JMP does), and indeed we use one for this blog, we chose to go with something else for Togethr.  Does that mean we don’t have hope for XMPP in the social space?  No, rather it is an admission that the largest network for people to interact with in this way exists on ActivityPub-compatible software, and people need a solution they can use today .

As it grows, Togethr gives us the “skin in the game” motivation to bridge these worlds.  We are not the only ones interested in bridging the XMPP and ActivityPub worlds together, in fact the Libervia project is currently working on a grant to produce a first version of a gateway, that should be generally usable later this year.  We hope to eventually roll out an update that makes every Togethr instance seamlessly be both ActivityPub and XMPP without anyone needing to change their address.

Why not wait until “everything is ready” to go live with XMPP and ActivityPub at the same time?  Well, people need a solution.  Many people fleeing silos or otherwise being attracted to federated social networking find that self-hosting is too complicated, or they just don’t have the time to dedicate to it.  Many of these people end up creating an account on a giant volunteer-run instance, joining yet another silo (albeit a nicely federated one) run by admins they don’t know with financial and mental pressures they cannot understand.

Togethr gives people looking to federate their digital social networking experience full control without requiring systems administration knowledge or time.  Our team not only keeps the instance running, but provides support for users who may not be familiar with the software or the fediverse in general and need help getting everything set up.  However, there is no lock-in and people can easily move to another host or self-hosting at any time.  For example, if someone got an instance and created the user person they would have address just like you would expect on any Fediverse instance.  However, since they control the domain they could move to a different host or self-host, point the domain at the new instance, copy over their data, and no one has to “follow me at my new address”, everything just keeps working.

While we believe that single-user instances are the pinnacle of federation, Togethr does not limit the way people want to use it.  People may have family or friends they want to share posts with, who might not be motivated to join the Fediverse but will accept a personal invitation.  So every Togethr instance allows the customer to invite whoever they would like to join them on the instance, in order to smooth the onboarding for friends and family.  We hope that this can provide an option for people looking to take control over more of their digital life.

  • wifi_tethering open_in_new

    This post is public /b/togethr-sopranica-social

  • Pl chevron_right

    Gajim: Gajim 1.4.0 / PlanetJabber · Wednesday, 11 May - 00:00 · 2 minutes

After more than a year of development, it’s finally time to announce the release of Gajim 1.4.0! 🎉 Gajim 1.4 series comes with a completely redesigned message window and conversation management. Workspaces allow you to organize your chats to keep matters separate where needed. These changes were only possible by touching a lot of Gajim’s code base, and we appreciate all the feedback we got from you.

What’s New

The new Gajim version comes with a completely redesigned main window. This window offers a sidebar containing workspaces, where you can organize all of your chats. Workspaces have been explained in detail last year . Each workspace holds a list of currently opened chats for both 1:1 chats and group chats. This makes it easy for you to keep matters separate. To make things simple and easy to use, we decided to migrate to a single window approach for Gajim. Chats opened via chat list will be displayed right next to it, keeping the window compact.

Gajim’s new main window

Gajim’s new main window

The way Gajim displays messages had not been changed for years. The previous approach had many limitations, but it was hard to replace it. Gajim 1.4 comes with a new approach, where each message is a separate ‘row’, which you can see in the above screenshot. This approach does not only look much cleaner, it also enables us to implement new features in the future, thinking of message reactions, replies, and so on.

For these changes to be implemented, we had to touch and refactor a good part of Gajim’s code base. Please report any issue you find! We appreciate your feedback.

Windows users please note: Windows builds are now based on Python 3.9, which does not run on Windows 7 or older.

More Changes


  • Redesigned Contact Info and Group Chat Info windows
  • Redesigned Group Chat Creation window
  • Full compatibility with XEP-0393 Message Styling
  • Real-time message styling in the chat input box
  • URL Image Preview, Plugin Installer, Syntax highlighting, and AppIndicator plugins have been integrated into Gajim
  • Support for XEP-0425 Message Moderation in group chats
  • Administrators can now define setting overrides


  • Reworked notification system
  • History manager has been replaced by Gajim’s internal search
  • ‘Note to myself’ feature: write messages to your own contact (e.g. to another device)
  • Improved Windows installer
  • Improved contrast for light and dark themes
  • Bookmark management window has been removed (all actions are still available in Gajim’s user interface)
  • XEP-0174 Serverless Messaging via Zeroconf has been removed
  • Client certificate setup has been removed
  • User Mood ( XEP-0107 ) and User Activity ( XEP-0108 ) have been removed


Over 120 issues have been fixed in this release

Have a look at the changelog for the complete list.


As always, don’t hesitate to contact us at or open an issue on our Gitlab .

  • wifi_tethering open_in_new

    This post is public /post/2022-05-11-gajim-1.4.0-released/

  • Pl chevron_right

    Paul Schaub: Creating an OpenPGP Web-of-Trust Implementation – A Series / PlanetJabber · Friday, 6 May - 10:18 · 4 minutes

I am excited to announce that PGPainless will receive funding by NGI Assure to develop an implementation of the Web-of-Trust specification proposal!

The Web-of-Trust (WoT) serves as an example of a decentralized authentication mechanism for OpenPGP. While there are some existing implementations of the WoT in applications such as GnuPG, their algorithms are often poorly documented. As a result, WoT support in client applications is often missing or inadequate.

This is where the aforementioned specification comes into play. This document strives to provide a well-documented description of how to implement the WoT in an interoperable and comprehensible way. There is already an existing implementation by the Sequoia-PGP project (Neal, the author of the specification is also heavily involved with Sequoia) which can serve as a reference implementation.

Since I imagine implementing the Web-of-Trust isn’t a straight-forward task (even though there is now a specification document), I decided to dedicate a series of blog posts to go along with my efforts. Maybe this helps others implementing it in the future.

What exactly is the Web-of-Trust?

The essential problem with public key infrastructure (PKI) is not to obtain the encryption keys for contacts, but rather verify that the key you have of a contact really is the proper key and not that of an attacker. One straight-forward solution to this is used by every user of the internet every day. If you visit a website on the internet, the web server of the site presents your browser with its TLS certificate. Now the browser has to figure out, if this certificate is trustworthy. It does so by checking if there is a valid trust-path from one of its root certificates to the sites certificate. Your browser comes with a limited set of root-certificates already preinstalled. This set was agreed upon by your browsers/OS vendor at some point. These root certificates are (mostly) managed by corporations who’s business model is to vouch for your servers authenticity. You pay them so that they testify to others that your TLS certificate is legitimate.

In this case, a trust-path is a chain of certifications from the trusted root certificate down to the sites TLS certificate. You can inspect this chain manually, by clicking the lock icon in your browsers task bar (at least on Firefox). Below is a visualization of the TLS certificate chain of this blog’s TLS certificate.

The certificate “ISRG Root X1” belongs to let’s encrypt , a not-for-profit CA that very likely is embedded in your browser already. R3 is an intermediate certificate authority of let’s encrypt. It certified my blogs TLS certificate. Since during the certificate renewal process let’s encrypt made sure that my server controls my domain, it has some degree of confirmation that in fact belongs to me. This step can be called manual identity verification. As a result, it can therefore attest the legitimacy of my TLS certificate to others.

One property of this model is that its centralized. Although there is a number of root certificates (hundreds in fact, check your /etc/ssl/certs/ directory!), it is not trivial to set up your own, let alone get browser/OS vendors to include it in their distributions.

Now lets take a look at the Web-of-Trust instead. The idea that describes the difference between the centralized TLS model and the WoT best, is that people trust people instead of corporations . If Alice trusts and vouches for Bob, and Bob trusts and vouches for Charlie, Alice could transitively trust Charlie. These trust paths can get arbitrarily long and the whole network of trust paths is what we call the Web-of-Trust. Instead of relying on a more-or-less trustworthy certificate authority to attest key authenticity, we gather evidence for the trustworthiness of a key in our social circle.

This model can be applied to corporate environments as well by the way. Let’s say FooBank is using the Web-of-Trust for their encrypted email traffic. FooBanks admin would be tasked with keeping a list of the email addresses of all current employees and their encryption keys. They would then certify these keys by signing them with a company key which is kept secure. These certification signatures are valid as long as the employee is working at the bank. Other employees would in return sign the company key and mark it as trustworthy. Now they can build a trust path from their own key to that of each other current employee. In that sense, the CA model can be seen as a special case of the Web-of-Trust.

The main problem now is to find an algorithm for determining whether a valid trust path exists between our trust-root and the certificate of interest. You might wonder “What is the trust-root? I thought the WoT comes without centralized trust in a single entity?”. And you are right. But we all trust ourselves, don’t we? And we trust ourselves to decide whom to trust. So to realize the WoT, we define that each user has their own “trust-root” certificate, which is a single certificate that certifies “trusted introducers”. This is the start of the trust-path. In case of FooBank, Employee Albert might for example have a personal trust-root certificate that certifies FooBanks CA key, as well as that of Alberts wive Berta. Now Albert can securely message any FooBank employee, as well as his wive, since there are trust-paths available from his trust-root to those contacts.

Luckily, the problem of finding an algorithm to determine trust-paths is already solved by the Web-of-Trust specification. All that’s left to do is to understand and implement it. That cannot be that hard, can it?

To be continued…

  • wifi_tethering open_in_new

    This post is public /2022/05/06/creating-an-openpgp-web-of-trust-implementation-a-series/

  • Pl chevron_right

    The XMPP Standards Foundation: The XMPP Newsletter April 2022 / PlanetJabber · Thursday, 5 May - 00:00 · 8 minutes

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of April 2022.

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, especially throughout the current situation, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

Newsletter translations

This is a community effort, and we would like to thank translators for their contributions. Volunteers are welcome! Translations of the XMPP Newsletter will be released here (with some delay):

XSF Announcements

XSF and Google Summer of Code 2022

  • The XSF has been accepted as hosting organization at Google Summer of Code 2022 (GSoC) .
  • XMPP Newsletter via mail: We migrated to our own server for a mailing list in order to move away from Tinyletter. It is a read-only list on which, once you subscribe to it, you will receive the XMPP Newsletter on a monthly basis. We moved away from Tinyletter due to privacy concerns.
  • By the way, have you checked our nice XMPP RFC page ? :-)

XSF fiscal hosting projects

The XSF offers fiscal hosting for XMPP projects. Please apply via Open Collective . For more information, see the announcement blog post . Current projects:

XMPP Community Projects

A new community space for XMPP related projects and individuals has been created in the Fediverse! Join us on our new Lemmy instance and chat about all XMPP things!


Are you looking for an XMPP provider that suits you? There is a new website based on the data of XMPP Providers . XMPP Providers has a curated list of providers and tools for filtering and creating badges for them. The machine-readable list of providers can be integrated in XMPP clients to simplify the registration. You can help by improving your website (as a provider), by automating the manual tasks (as a developer), and by adding new providers to the list (as an interested contributor). Read the first blog post !

XMPP Providers



Thilo Molitor presented their new even more privacy friendly push design in Monal at the Berlin XMPP Meetup!

Monal push


The Mellium Dev Communiqué for April 2022 has been released and can be found over on Open Collective .

Maxime “pep.” Buquet wrote some thoughts regarding “Deal on Digital Markets Act: EU rules to ensure fair competition and more choice for users” in his Interoperability in a “Big Tech” world article. In a later article he describes part of his threat model , detailing how XMPP comes into play and proposing ways it could be improved.

German “Freie Messenger” shares some thoughts on interoperability and the Digital Markets Act (DMA). They also offer a comparison of “XMPP/Matrix”

Software news

Clients and applications

BeagleIM 5.2 and SiskinIM 7.2 just got released with fixes for OMEMO encrypted message in MUC channels, MUC participants disappearing randomly, and issues with VoIP call sending an incorrect payload during call negotiation.

converse.js published version 9.1.0 . It comes with a new dark theme, several improvements for encryption (OMEMO), an improved stanza timeout, font icons, updated translations, and enhancements of the IndexedDB. Find more in the release notes .

Gajim Development News : This month came with a lot of preparations for the release of Gajim 1.4 🚀 Gajim’s release pipeline has been improved in many ways, allowing us to make releases more frequently. Furthermore, April brought improvements for file previews on Windows.

Go-sendxmpp version v0.4.0 with experimental Ox (OpenPGP for XMPP) support has been released.

JMP offers international call rates based on a computing trie . There are also new commands and team members .

Monal 5.1 has been released . This release brings OMEMO support in private group chats, communication notifications on iOS 15, and many improvements.

PravApp project is a plan to get a lot of people from India to invest small amounts to run an interoperable XMPP-based messaging service that is easier to join and discover contacts, similar to the Quicksy app. Prav will be Free Software, which respects users' freedom. The service will be backed by a cooperative society in India to ensure democratic decision making in which users can take part as well. Users will control the privacy policy of the service.

Psi+ 1.5.1619 (2022-04-09) has been released.

Poezio 0.14 has been released alongside with multiple backend libraries. This new release brings in lots of bug fixes and small improvements. Big changes are coming, read more in the article.

Poezio Stickers

Profanity 0.12.1 has been released, which brings some bug fixes.

UWPX ships two small pre-release updates concering a critical fix for a crash that occurs when trying to render an invalid user avatar and issues with the Windows Store builds . Besides that it also got a minor UI update this month.


Ignite Realtime Community:

  • Version 9.1.0 release 1 of the Openfire inVerse plugin has been released, which enables deployment of the third-party Converse client 37 in Openfire.
  • Version 4.4.0 release 1 of the Openfire JSXC plugin has been released, which enables deployment the third-party JSXC client 13 in Openfire.
  • Version 1.2.3 of the Openfire Message of the Day plugin has been released, and it ships with German translations for the admin console
  • Version 1.8.0 of the Openfire REST API plugin has been released, which adds new endpoints for readiness, liveliness and cluster status.


slixmpp 1.8.2 has been released. It fixes RFC3920 sessions, improves certificate errors handling, and adds a plugin for XEP-0454 (OMEMO media sharing).

The library v0.21.2 has been released! Highlights include support for PEP Native Bookmarks , and entity capabilities . For more information, see the release announcement .

Extensions and specifications

Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001 , which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process . Communication around Standards and Extensions happens in the Standards Mailing List ( online archive ).

By the way, features a new page about XMPP RFCs .


The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.


  • No new XEPs this month.


If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.

  • No XEPs deferred this month.


  • Version 0.4 of XEP-0356 (Privileged Entity)
    • Add “iq” privilege (necessary to implement XEPs such as Pubsub Account Management ( XEP-0376 )).
    • Roster pushes are now transmitted to privileged entity with “roster” permission of “get” or “both”. This can be disabled.
    • Reformulate to specify than only initial stanza and “unavailable” stanzas are transmitted with “presence” pemission.
    • Namespace bump. (jp)

Last Call

Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call help improving the XEP before returning it to the Council for advancement to Stable.

  • No Last Call this month.


  • No XEPs advanced to Stable this month.


  • No XEP deprecated this month.

Call for Experience

A Call For Experience - like a Last Call, is an explicit call for comments, but in this case it’s mostly directed at people who’ve implemented, and ideally deployed, the specification. The Council then votes to move it to Final.

  • No Call for Experience this month.

Spread the news!

Please share the news on other networks:

Subscribe to the monthly XMPP newsletter

Also check out our RSS Feed !

Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board .

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. Therefore, we would like to thank Adrien Bourmault (neox), anubis, Anoxinon e.V., Benoît Sibaud, cpm, daimonduff, emus, Ludovic Bocquet, Licaon_Kter, mathieui, MattJ, nicfab, Pierre Jarillon, Ppjet6, Sam Whited, singpolyma, TheCoffeMaker, wurstsalat, Zash for their support and help in creation, review, translation and deployment. Many thanks to all contributors and their continuous support!

Each month’s newsletter issue is drafted in this simple pad . At the end of each month, the pad’s content is merged into the XSF Github repository . We are always happy to welcome contributors. Do not hesitate to join the discussion in our Comm-Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.

Tasks we do on a regular basis:

  • gathering news in the XMPP universe
  • short summaries of news and events
  • summary of the monthly communication on extensions (XEPs)
  • review of the newsletter draft
  • preparation of media images
  • translations


This newsletter is published under CC BY-SA license .

  • wifi_tethering open_in_new

    This post is public /2022/05/the-xmpp-newsletter-april-2022/

  • Pl chevron_right

    Gajim: Development News April 2022 / PlanetJabber · Saturday, 30 April - 00:00 · 1 minute

This month came with a lot of preparations for the release of Gajim 1.4 🚀 Gajim’s release pipeline has been improved in many ways, allowing us to make releases more frequently. Furthermore, April brought improvements for file previews on Windows.

Changes in Gajim

For two and a half years I (wurstsalat) have been writing (and translating) Gajim’s monthly development news. Keeping this up on a monthly basis takes a lot of time and effort. Upcoming development news will be released on an irregular basis, focussing on features instead of monthly progress.

It has been a while since the release of Gajim 1.3.3. But why does it take so long until a new version gets released? One of the reasons is the amount of manual work it takes to update every part of Gajim’s internals for a new release. This does not include functional changes, but only things which need to be updated (version strings, translations, changelogs, etc.) before a new version can be deployed. Note that Gajim is available for multiple distributions on Linux, for Flatpak, and for Windows, which makes releasing a new version more complicated. In order to make releases happen more frequently, i.e. reducing the manual work involved in deploying a new version, great efforts have been made:

  • deployment pipelines have been established on Gajim’s Gitlab
  • the process of applying Weblate translations has been integrated better
  • changelogs will be generated automatically from git ’s commit history
  • Flatpak update process has been simplified

There are more improvements to come, but this should already make deploying a new version much easier.

What else happened:

  • Sentry integration has been improved
  • libappindicator is now used on Wayland, if available
  • downloading a file preview can now be cancelled
  • mime type guessing for file previews has been improved on Windows
  • audio previews are now available on Windows
  • Security Labels ( XEP-0258 ) selector has been improved
  • improvements for private chat messages

Plugin updates

Gajim’s OpenPGP plugin received an update with some usability improvements.

Changes in python-nbxmpp

python-nbxmpp is now ready for being deployed quickly as well.

As always, feel free to join to discuss with us.


  • wifi_tethering open_in_new

    This post is public /post/2022-04-30-development-news-april/

  • Pl chevron_right

    JMP: Newsletter: New Staff, New Commands / PlanetJabber · Wednesday, 27 April - 21:00 · 1 minute

Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update!

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client.  Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

The JMP team is growing.  This month we added root , whom many of you will know from the chatroom.  root has been a valuable and helpful member of the community for quite some time, and we are pleased to add them to the team.  They will be primarily helping with support and documentation, but also with, let’s face it, everything else.

The account settings bot has a new command for listing recent financial transactions.  You can use this command to check on your auto top-ups, recent charges for phone calls, rewards for referrals, etc.  There is now also a command for changing your Jabber ID, so if you find yourself in a situation where you are changing for any reason you can do that yourself without waiting for support to do it manually.

This month also saw the release of Cheogram Android 2.10.5-2 .  This version has numerous bug fixes for crashes and other edge cases and is based on the latest upstream code which includes a security fix, so be sure to update!  Support for TOR and extended connection settings has also been fixed, a new darker theme added, and UI tweaks to recognize that messages are often encrypted with TLS.

To learn what’s happening with JMP between newsletters, here are some ways you can find out:

Thanks for reading and have a wonderful rest of your week!

  • wifi_tethering open_in_new

    This post is public /b/april-newsletter-2022

  • Pl chevron_right

    Erlang Solutions: What are the key trends in digital payments? part 2/2 / PlanetJabber · Monday, 25 April - 14:57 · 3 minutes

In the second and final part of this article, we take a look at some of the important developments in how payments work using our fintech industry knowledge and experience working on some of the most performant fintech systems in the world such as Vocalink’s Instant Payments Solution (IPS).

In part 1 we looked at the rapid growth in e-commerce, demand for faster payments and consumer adoption of relatively new ways of payments. You can read it in full here.

If you are involved in the payments industry in the Nordics region of Europe, make sure to catch up with our Nordics Managing Director, Erik Schön, who will be taking part in a panel discussion at NextGen Nordics taking place in Stockholm, Sweden, on 27 April.

Leveraging payments data

The diverse range of digital touchpoints involved in a cashless payments ecosystem provides vast amounts of data. This is of significant value to banks and fintechs to grow client relationships based on analytics and insights. Companies that can unlock the true value of payment activity data by leveraging powerful AI and ML tools can offer more efficient, tailored products and a more secure, protected environment in which to operate.

We can expect the full implementation of the messaging standard ISO20022 to be a potentially vital part of improving the amount and quality of payments data available in the industry. ISO20022, as the global standard for payment messaging, provides, for the first time, a shared language to be used for transactions made by anyone, anywhere.

Financial crime

All of the converging trends discussed here and in part 1 of this post present a clear dilemma in modern payments – customers are demanding easier in real-time transactions actioned on any connected device, while regulators are concerned about increased exposure to fraud. Payments companies, therefore, need to strike the right balance delivering new user-friendly processes that are also highly secure and compliant.

Rapidly increased e-commerce provides an opening for fraudsters. The use of AI and ML allows payment companies to detect fraud earlier by learning the financial habits of clients so that unusual behaviour is highlighted. Fraud prevention security measures, like voice-activated transactions, biometric authentication, and smart assistant payment verification, all have a part to play in securing the future of digital payments.

Future models of payments infrastructure

On the frontend, we are seeing more forms of instant payments and innovations such as digital wallets and embedded finance. Disruption of the payment industry is moving on from providing these user-friendly frontend mobile apps to improving backend processing and the infrastructure used to execute payments.

For instance, real-time payments technology and the utilisation of cryptocurrencies, stablecoins, CBDCs, blockchain, AI and ML, can all help improve the speed and security of payment gateway services used for cross-border and multi-channel payment systems that have suffered from being slow and expensive transaction fees.

With the emergence of blockchain and decentralised finance, transactions can bypass the traditional financial initiations altogether to enable direct payments between parties and revolutionise the industry.


The modern payments ecosystem is varied with lots of layers and companies filling niche use cases. Overall, it can be said that the journey towards more digital, open and real-time operations mirrors the way society at large is increasingly living online.

Many of the trends covered in this article may be set to converge in the emerging metaverse space, but the shape of that is some way from being determined. What will money look like in the metaverse? How will existing cross-border payment rails integrate with a borderless, global ecosystem?

To discuss the answer to these questions and the P27 response to the metaverse, you can join us at NextGen Nordics taking place in Stockholm, Sweden, on 27 April, where our Nordics Managing Director, Erik Schön, will be taking part in a panel discussion on the topic.

Our payments expertise

We help create digital and mobile payment solutions that facilitate e-commerce, payments processing and backend services that enhance the customer experience and protect customer data. We work with clients who provide services in DeFi, cryptocurrency, blockchain, GameFi, clearing and settlements, embedded finance, real-time payments, payment gateways and more.

Our solutions use battle-tested technologies delivered by domain experts for secure, compliant and resilient solutions.

Let’s start a conversation about your payments project >

To make sure you don’t miss more great fintech content from us, you should sign up for our Fintech Matters mailing list.

Sign up here >

The post What are the key trends in digital payments? part 2/2 appeared first on Erlang Solutions .

  • wifi_tethering open_in_new

    This post is public /blog/what-are-the-key-trends-in-digital-payments-part-2-2/