Planet Jabber

February 26, 2021

Monal IM

Monal 5 Beta 1

The following changes are ready to be tested in Monal 5. The Mac build is up for download here and iOS will be available on TestFlight soon. The Mac build address has been updated to a tar.gz file instead of zip. It should open the same. The link has been updated to use the new macOS name as well.

  • omemo to/from siskin/beagle now functional
  • showing of own omemo key qr codes for quick verification
  • persistence of trust levels even if omemo errors occur
  • qr code scanning for macOS
  • fixed crash on account deletion
  • don’t allow change of account jid
  • many small fixes
  • push server now uses xmpp for registering new push tokens (now the monal appserver never sees your ip)
  • catalyst (especially on apple silicon) now has real push support

ongoing development (half implemented):

  • scanning of omemo qr codes (wip: ui)
  • filetransfer ui (wip: audio messages, download percentage, file size limits for auto-downloads)
  • muc support (working: entering mucs and muc-mam to load messages after extended offline periods)

by Anu at February 26, 2021 03:00

February 25, 2021


Development News February 2021

February brings many bug fixes for the upcoming Gajim 1.3.1 release. The Profile window’s error handling has been improved, and selecting small images for an avatar should now work as expected. While fixing those bugs, we’ve been working on something big.

Changes in Gajim

Roughly a month ago, we started a rework of Gajim’s main window. This will bring fundamental changes to Gajim, but it will also take some time until it’s ready to be shown. Many core functionalities are tied to the ‘roster window’, which displays your contact list. This is due to Gajim being grown around the contact list acting as the main entry point for almost every action. Currently, we’re in the process of untying those functionalities in order to separate them from the contact list. While this work happens mostly in the background, we managed to fix a good portion of new bugs which showed after the release of Gajim 1.3.0. Thanks everyone for reporting issues!

What else happened

  • Added setting to explicitly enable GSSAPI authentication
  • Added account badge for group chat invitations #10424
  • Removed ASCII Emoji replacing mechanism for incoming messages (Gajim now displays them as intended by the sender)
  • Better error handling for the new Profile window
  • Improved avatar selector (works now for images <100 px)
  • Improved accounts window layout #10438
  • Account Creation: Links offered by servers during registration are now clickable #10445
  • Gajim now displays an error if gateway registration fails #10443
  • Fixed horizontal scrollbar sometimes appearing in the chat window
  • Fixed crash which appeared when trying to open the Contact Information window for offline contacts #10273
  • Fixed crash occurring when clicking a ‘connection failed’ notification #10436
  • Fixed rare crash which occurred when disabling video preview in preferences #10430

Plugin updates

Gajim’s URL Image Preview plugin now respects EXIF rotation when generating previews.

Changes in python-nbxmpp

python-nbxmpp 2.0.1 and 2.0.2 have been released, addressing multiple bugs. GSSAPI authentication has to be enabled explicitly, since it could lead to complications when other mechanisms are available as well. Furthermore, an issue with the publication of avatars has been fixed.

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


February 25, 2021 00:00

February 24, 2021

Monal IM

Redesign of the Monal logo

Hello everyone,

with support from Anu & Thilo I am organizing the community project to redesign the Monal logo. After the suggestion’s have been made we would like to ask the community to vote and what should be done. No worries, there will be the option to keep the current one, if a majority votes for this.

There are a few criteria:

– Have a similar coloring scheme

– Try to keep it suitable to the Monal name / “brand” and for the community

– You agree to publish this under the same license as Monal is and do not use material that has copyright not enabling the use in this project

– Provide it as SVG file (it is not are hard criteria but would be really helpful for us!)

– Please hand in before the **31st of March 2021**

Please publish your suggestion on Github. If you have multiple suggestions or versions please post each in a separate comment. If you don’t have the option to publish on Github, please reach out to the developers.

We will likely call for final voting outside of GitHub, but feel free to us the platform vote function. Please respect the work of other, if you like it or not.

Best regards

by emus at February 24, 2021 21:01

February 23, 2021

Monal IM

Monal 5 will support inline audio and video

Monal 5 will be another big update with a lot of changes under the hood. Thanks to Jim this will add support for inline audio and video playback.

by Anu at February 23, 2021 19:40

February 15, 2021

Prosodical Thoughts

Prosody 0.11.8 released

We are pleased to announce a new minor release from our stable branch.

A new release appears! This time it includes bug fixes and performance improvements!

Thanks to the Jitsi folks for helping us improve websocket performance in this and the previous release.

This release also fixes a security issue, where channel binding, which connects the authentication layer (i.e. SASL) with the security layer (i.e. TLS) to detect man-in-the-middle attacks, could be used on connections encrypted with TLS 1.3, despite the holy texts declaring this undefined.

A summary of changes in this release:


  • mod_saslauth: Disable ‘tls-unique’ channel binding with TLS 1.3 (#1542)

Fixes and improvements

  • net.websocket.frames: Improve websocket masking performance by using the new util.strbitop
  • util.strbitop: Library for efficient bitwise operations on strings

Minor changes

  • MUC: Correctly advertise whether the subject can be changed (#1155)
  • MUC: Preserve disco ‘node’ attribute (or lack thereof) in responses (#1595)
  • MUC: Fix logic bug causing unnecessary presence to be sent (#1615)
  • mod_bosh: Fix error if client tries to connect to component (#425)
  • mod_bosh: Pick out the ‘wait’ before checking it instead of earlier
  • mod_pep: Advertise base PubSub feature (#1632)
  • mod_pubsub: Fix notification stanza type setting (#1605)
  • mod_s2s: Prevent keepalives before client has established a stream
  • net.adns: Fix bug that sent empty DNS packets (#1619)
  • net.http.server: Don’t send Content-Length on 1xx/204 responses (#1596)
  • net.websocket.frames: Fix length calculation bug (#1598)
  • util.dbuffer: Make length API in line with Lua strings
  • util.dbuffer: Optimize substring operations
  • util.debug: Fix locals being reported under wrong stack frame in some cases
  • util.dependencies: Fix check for Lua bitwise operations library (#1594)
  • util.interpolation: Fix combination of filters and fallback values #1623
  • util.promise: Preserve tracebacks
  • util.stanza: Reject ASCII control characters (#1606)
  • timers: Ensure timers can’t block other processing (#1620)


As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

by The Prosody Team at February 15, 2021 19:39

February 09, 2021


Products vs Protocols: What Signal got right

There is a significant difference between developing and promoting a protocol (such as XMPP) and a product (such as Signal). Both approaches have their advantages and disadvantages. This post details how and why Snikket aims to strike a balance between the two.

Products vs Protocols

This past weekend I gave a talk at the (virtual) FOSDEM conference about a topic I’ve been thinking about a lot the past few years - the differences between developing a product and developing a protocol.

You can watch the talk here, but there were many things I wanted to touch upon that wouldn’t fit into the 20 minute slot. This post will cover the same topics, but expands on some of the points I discussed.

Previously, in open protocols…

I’ve been involved with XMPP (once known as Jabber) for over 15 years. It is now over 20 years since XMPP’s inception, and over this time XMPP, along with the rest of the tech industry, has seen significant change.

XMPP began life in the late 1990s, as an attempt to break into the messaging silos of that era. The names and logos may have been different, but it was a very similar landscape to today - oversized tech companies fighting each other for control over people who simply want to use the internet for what it was designed, communicating with one another.

Email got lucky. A standard protocol managed to break down the walls of even the final fortress of resistance, AOL. This was achieved largely because the adoption of standard protocols by smaller providers allowed them to form a network together that began to threaten even America’s largest ISP.

Unfortunately we never quite reached that point with instant messaging. However that hasn’t stopped many of us from continuing to strive for a similar outcome even as our symbol of hope, the open email network, is under threat today more than ever before.

Despite numerous projects, communities and organizations campaigning for decades in favour of open messaging systems, the space is still dominated by large silos. The largest the world has ever known. WhatsApp alone has over 2 billion users. That means a significant portion of the world’s communications are flowing through a single company. A company that has a simple business model - amassing data about people and leveraging that data to help their actual customers (other businesses) influence the beliefs, biases and behaviour of the users of their platforms.

The slippery slope

Despite the dizzying numbers associated with WhatsApp today, it had more humble beginnings. Founded by two ex-Yahoo employees, Brian Acton and Jan Koum, it began as a simple messaging app for iPhones. The server was originally based on an open-source XMPP server, and used the XMPP protocol. However the goal of WhatsApp was not openness and federation, and they soon diverged far from standard XMPP.

As WhatsApp grew, early users may recall that they also began charging a small fee for accounts ($1/year). Their reasoning was simple:

“Remember, when advertising is involved you the user are the product.

Your data isn't even in the picture. We are simply not interested in any of it.

When people ask us why we charge for WhatsApp, we say ‘Have you considered the alternative?’“

WhatsApp blog post “Why we don't sell ads“, June 2012

Nevertheless, just two years later it was announced that WhatsApp had been acquired by the internet’s fastest-growing advertising platform, Facebook.

Despite declaring to the EU competition commission that linking an individual’s data between WhatsApp and Facebook was not technically feasible this is exactly what they went on to do, leading to a €94 million fine. Little by little, Facebook has been loosening their privacy policies to allow them to absorb WhatsApp data into their daily operations.

So when, in early 2021, the latest update to the privacy policy gave users of the platform a clear ultimatum to allow this sharing or close their account, many users wisely began to seek alternatives. Finally, the moment we had been waiting for had arrived.

Many of us advocates of open communications seized the opportunity, and recommendations were soon flying around for the wide range of alternative messaging systems we’ve been building these past years. “Use XMPP!”, “Use Matrix!”, “Use Signal!”, to name a few.

Despite a marked increase of signups on XMPP and Matrix servers, of these three it was Signal that won by far the largest share of new users. Millions of people flocked from WhatsApp and overloaded Signal’s servers, resulting in disrupted message delivery across Signal’s service for days.

This service disruption was possible because, unlike XMPP and Matrix, Signal is centralized, and all messages flow through a single set of servers, the same model as WhatsApp.

XMPP and Matrix are both federated networks. Rather than a single entity controlling the network, there are many servers to choose from, run by many different independent providers. Even with a server down, overloaded or closed to new users, the rest of the network continues functioning.

So why did Signal receive millions of users, and XMPP/Matrix did not?


At this point it’s impossible not to reference The Ecosystem is Moving, a 2016 blog post by Signal’s founder and CEO, Moxie Marlinspike. In this post Moxie details all the problems he sees with protocols becoming open internet standards. In particular, that they lose their ability to evolve, and that evolution is vital to compete in our industry’s “moving ecosystem”.

We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s.

Signal blog post “The ecosystem is moving“, May 2016

Well. Far from being frozen in time, XMPP has changed significantly in the past 20 years.

Just some of the things we have now that we didn’t have in the beginning:

  • End-to-end encryption using OMEMO (based on Signal’s protocol and audited), with multi-device and offline capabilities
  • Audio/video calling (now 2nd generation, encrypted, WebRTC-compatible)
  • Mobile optimizations (bandwidth, connectivity, push notifications)
  • Full cross-device message synchronization

Many of these things didn’t even exist as concepts back when XMPP began. Adding them was only possible due to XMPP’s smart design: a core protocol, with a suite of extensions (known as XEPs). New extensions are added as needed, and irrelevant ones get deprecated.

To help keep everyone on the same page as the protocol evolves, the XMPP Standards Foundation (XSF) annually publishes the recommended XEPs that different classes of software (e.g. instant messaging, social networking, or smart devices) should be implementing. These round-ups are known as compliance suites.

The documentation site Modern XMPP also serves as a useful reference guide for modern XMPP implementations (including UI/UX considerations, which are not covered by the protocol-level documentation).

The unfortunate truth

The effort required in advancing the protocol is significant. And that’s not even counting the implementation work. XMPP has a diverse and open ecosystem. There is no single “XMPP client”, instead the ecosystem is composed of… just about anyone who decides to write XMPP software. The vast majority of this software is free/open-source, and developed by volunteers and communities.

Publishing protocol updates does not magically mean the changes are implemented in all XMPP software overnight. Some projects are more active than others, and each contributor is an individual with their own life and work schedule. Unfortunately this means that it’s very difficult to evolve the protocol and keep everyone 100% in sync. Luckily XMPP’s modular design makes it easy for some software to advance ahead of others without having to lose backwards compatibility with the rest of the network. If we didn’t have this feature, we would always be in a state where half of the network is unable to communicate with the other half of the network, or more likely we would be stuck with the initial set of features because nobody would want to be the first ones to become incompatible with everyone else.

But Moxie is right. We could move much faster if we didn’t care about interoperability, software diversity, and decentralization.

And that is the approach Signal is taking.

Product or protocol?

It’s clear that there are trade-offs to be made here. Signal’s product-led development excludes others from participating in the Signal network. But it allows them to remain agile, and implement new features as fast as they can write and ship code.

I put together some of the trade-offs into the following table:

Building an ecosystem Building a product
Focus on protocol Focus on implementation
Mostly documentation Mostly code
Cross-project collaboration Single project/team
Building for developers Building for end-users
Slow evolution Evolves as fast as you want
Achieve diversity Achieve a monoculture
Robust Single point of failure

I think that Signal’s approach is laudable for the number of people that they have helped divert from data-mining platforms, and helping to remind people that surveillance capitalism isn’t the only way to do things.

They’ve built a good user-friendly product, and they have done it with security and privacy at its heart.

But we have to aspire to more than this. Signal is a centralized, closed system. That means to communicate with your contacts who use Signal, you must also consent to their terms, their software, their US jurisdiction. You have to be okay with their servers being hosted with large cloud providers such as Amazon and Google.

But one thing the past has shown us is that things change. Technologies evolve, business leaders come and go, motives adjust. Signal today may be as benign as WhatsApp before its acquisition by Facebook. But change is inevitable, from whatever direction it comes. Signal is a technical, organizational and political point of failure.

Best of both worlds

Thinking about the table I presented above. Consider that perhaps the options on each row are just the extreme positions. Perhaps we can try to strike a balance between them - making intelligent choices as we go.

What if we could make a Signal that was a little more open? And an XMPP that was a little bit less diverse? Accept that we would trade some of the agility for robustness, and some of our diversity in favour of consistent usability.

Can we move beyond Signal’s flaws to build something that is open, interoperable, user-friendly, consistent and decentralized? I believe so, and as they say, there’s only one way to find out.


Snikket is an initiative to bring a more product-led approach to the XMPP ecosystem. It’s a project that will deliver a suite of XMPP software: a single app for each platform, and an easy to deploy server for self-hosting.

The goal is to reduce fragmentation in the XMPP ecosystem, and ensure that people have access to a familiar brand across all platforms. This brand will represent a consistent set of features, and no interoperability issues. The software is all open-source, and of course still (the latest and greatest) XMPP.

Hopefully Snikket will also become an easy gateway to the world of XMPP for users who may previously have found it inaccessible due to the need to understand the ecosystem and choose the best software for each platform. All the other XMPP software continues to exist, and people are free to use anything that better suits their needs.

Starting from scratch would be a massive undertaking, and would require resources beyond the reach of an unfunded open-source project. Instead we are building on top of the amazing work that is already being done in XMPP implementations. For our Android client we selected Conversations. For iOS, Siskin. The server is based on Prosody.

All of these projects are good projects on their own. But by combining them under a single brand, performing focused interoperability testing and improving UI/UX consistency, we gain a new project that is greater than the sum of its components.

To be clear, these are not “hard forks” of the projects. Quite the opposite. We work closely with the developers, and have sponsored features in both Conversations and Siskin to get to where we are today. Our work on invite-based onboarding grew into a whole new feature in Prosody. Everything that makes sense in the upstream project gets pushed upstream. Lessons learned in UI/UX will likewise get added to the Modern XMPP documentation for other client developers to benefit from.

Snikket is not about replacing any of the individual projects, but about joining them together in a neat way and extending XMPP’s reach to new audiences.

Back to the future

Will Snikket alone turn the tide against proprietary communication platforms? Maybe, maybe not. But we’re part of a growing movement that agrees it’s time to stop repeating history, and finally redecentralize the internet, the way it was intended.

Thanks to Kim Alvefur, Georg Lukas and Jonas Schäfer for their editorial review during the writing of this post.

Want to help support the project? Donations are welcome! All contributions will help us to continue work on the project and accomplish the goals on our roadmap. Want to talk? Join our community chat.

by Snikket Team ( at February 09, 2021 12:51

February 08, 2021


Gajim 1.3.0

Five months have passed since the release of Gajim 1.2.2. Many new features have been developed during this time, including a complete redesign of both Gajim’s Preferences window and configuration backend, an all new Profile window, support for Chat Markers, a new user interface for voice/video calls, and much more.

What’s New


A huge amount of code has been cleaned up around Gajim’s configuration backend. This was necessary in order to move from a configuration based on text files to a new settings backend powered by SQLite. Gajim is now able to store settings efficiently, and some quirks around default values have been solved. After all these changes under the hood, it was time to redesign the Preferences window. The redesign enables us to display settings in a tidy and clear fashion, which should make it easier for you to handle all of Gajim’s configuration possiblities.

Gajim’s Notification settings for event handling have been split up. You can now decide if you want notifications to be shown in general, and if you want new messages to be opened directly (without a notification icon in the contact list). All settings around sending Chat States (e.g. ‘Composing…') have been moved from the Preferences window to the Accounts window, completing the migration of account-related settings. Gajim uses a ‘Sync Threshold’ setting to decide how many messages should be synchronized when joining a chat. If you set a custom Sync Threshold previously, please make sure to check the setting after upgrading Gajim, since it could not be migrated.

Gajim’s new Preferences window

Gajim’s new Preferences window

Chat Markers

A long anticipated feature has finally found its way to Gajim: Chat Markers (XEP-0333). You already know the check mark which Gajim shows as soon as a message has been delivered (XEP-0184). Now, as soon as your contact reads your message, you’ll notice a double check mark replacing the single check mark, marking the message as ‘read’. This is of course on the condition that your contact’s chat client actually sends Chat Markers. Gajim lets you choose whether you want to send these markers via Account Settings > Privacy > Send Read Markers. As soon as you read a message on another device (e.g. your phone), Gajim will remove the now obsolete notification. By default, this works for 1:1 chats and private group chats (tested with Conversations and Dino).


Gajim’s Profile window received a complete rework. This includes a new backend using up to date standards (XEP-0292 vCard4 Over XMPP), as well as a completely rewritten dialog for displaying and editing vCards.

A big advantage over the old Profile window is that you can add (almost all) elements more than once. For example, you can add an email address for your workplace, and additionally a private one. Or multiple organisations, or even more PGP keys, … All these elements are added dynamically, there is no static user interface here.

Selecting your own profile picture is much more fun if you can crop it directly using integrated tools. This is now possible using the new picture selector, which enables you to select the detail you want to show, using a fixed aspect ratio.

Group Chat Invitations

Receiving a group chat invitation can sometimes be ambiguous. ‘Do I really want to join this chat, or should I decline the invitation?’ In order for you to make an informed decision, Gajim now shows some information about the chat (group chat’s picture, name, and description) before joining. Furthermore, many people want to join public group chats using a different nickname from the one they use for private group chats. Gajim now offers to choose a nickname directly before joining.

The new Group Chat Invitation window

The new Group Chat Invitation window

Audio & Video

Last but not least, there have been some improvements to Voice/Video calling. Gajim has had support for Voice/Video calls for quite some time, but the code has also been broken for a while now, because it is not actively maintained. We took some first steps (friendlier user interface, basic audio/video transmission), but these are highly experimental. Also, this feature is based on older standards, which makes it incompatible with Conversations for the time being (for example missing support for XEP-0320).

Plugin Updates

  • Gajim’s URL Image Preview is now able to preview audio files
  • The Syntax Highlighter plugin now features a ‘Paste as Code’/‘Paste as Code Block’ entry for the chat input
  • It is now possible to install the ‘Ayatana Appindicator integration’ plugin via Flatpak

More Changes


  • Setting for automatic history cleanup
  • Chat-specific ‘Group Chat Settings’ page
  • ‘Mark as Read’ button for message notifications
  • ‘Send Message’ button in chat windows
  • Support for vCard4 (XEP-0292)
  • Windows: support for XMPP link handling
  • Added a preview when pasting images from the clipboard


  • Gajim will use direct messages in non-anonymous group chats instead of PMs (this is configurable)
  • Message styling: removed _underline_ style and added ~strikethrough~ style, making Gajim standard compliant
  • Removed notification for contact sign in/out
  • Removed ‘Auto copy’ workaround for Ctrl+C usage in the chat window
  • If Gajim fails to join a group chat, it now offers a Retry button (and also ‘Forget Group Chat’)
  • Changed default: Pressing the Escape key will not close chat windows
  • Linux: Emoji button now opens GTK’s native Emoji chooser (with categories and recently used emojis)
  • Improved A/V codec selection
  • Fixed some regressions with non-english keyboard layouts
  • Fixed command for opening the Start Chat window (gajim --start-chat)
  • A/V menu entries are now updated (enabled/disabled) correctly when receiving the contact’s capabilities
  • Fixed GSSAPI support
  • Some shortcuts now use Primary (Ctrl/Cmd) instead of Alt (which is often used by Window Management): Change Subject (<Primary><Shift>S), Emoji Chooser (<Primary><Shift>M)
  • Fixed a bug where dropping selected text on a chat window would fail
  • Fixed ‘Show status changes’ setting being ignored for group chats
  • Fixed a bug where removing a plugin would fail
  • And much more: Have a look at the full changelog

Known Issues

  • On Windows, we had to disable translations temporarily. This is due to a bug in a package Gajim relies on. Hopefully we’ll be able to ship the next version with translations again!
  • Zeroconf (serverless messaging) has not been re-implemented yet
  • Client certificate setup is not possible yet


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

February 08, 2021 00:00

February 07, 2021

Monal IM

Monal 5 betas

Mac beta is ready and available for download. The iOS one will come soon to testflight. This matches what used to be the alphas. Going forward the hope is to have just these regular builds and possibly nightly alphas published here (depending on how the CI work goes)

by Anu at February 07, 2021 03:39

February 05, 2021

Monal IM

GitHub reorganization

Monal is growing! That means we need to improve the way we collaborate and manage the various projects that build the client and server stack that makes it tick. With that in mind the development team is migrating from a collection of personal accounts to an organization in GitHub. Monal related projects are now in the monal-Im organization . This shouldn’t break any existing links the source code, bug reports or tickets. Please let us know if you do encounter any issues.

by Anu at February 05, 2021 21:00

Ignite Realtime Blog

Openfire 4.6.2 is released

The Ignite Realtime Community is pleased to announce the 4.6.2 release of Openfire. For SQL Server users, this release contains an important fix that prevented a database upgrade script from working. Otherwise, the changelog denotes three other issues resolved. One change to note is a subtle difference on the Openfire administration console with how the version is reported in the upper right corner. For example:


The git repository commit hash the build was based off of is included to provide a more definitive provenance of the version you are running. In this case, “b61bce3” refers to the merge commit for the 4.6.2 release.

Release artifacts can be found on our download page and they have the following sha1sum values

678f7ca008ed8347f4b49efcac3ef68cde9814ed  openfire-4.6.2-1.i686.rpm
10db897faff66be5228fde858da7618becee1251  openfire-4.6.2-1.noarch.rpm
29c7aa59cac59eb15b0824e5a7d1dde0ce57976b  openfire-4.6.2-1.x86_64.rpm
245e326efbcf02749a243ef7bee79a55b6b5afb3  openfire_4.6.2_all.deb
1e9f0eb71650313f65848d376b600d6ce2d87db7  openfire_4_6_2_bundledJRE.exe
1f80ba8835c55f7290ac05f2b88cffdd3a993616  openfire_4_6_2_bundledJRE_x64.exe
d9c0956ad8fcc28e27b92175e6931841f76b0935  openfire_4_6_2.dmg
2c610a40648547aa37093fa0d73ce2e9eca4a0af  openfire_4_6_2.exe
c03ede9ee3693cccc5f95d2155637d0269567edf  openfire_4_6_2.tar.gz
9192fcf7ac6abca3578e1720155723da0792ba98  openfire_4_6_2_x64.exe
a9a2dab04c03cccb5b1b371602dbea87dc860fd3  openfire_src_4_6_2.tar.gz

And for those curious, here is an accounting of the number of 4.6.1 downloads by artifact.

Artifact Downloads
openfire-4.6.1-1.i686.rpm 182
openfire-4.6.1-1.noarch.rpm 429
openfire-4.6.1-1.x86_64.rpm 1148
openfire_4.6.1_all.deb 2501
openfire_4_6_1.dmg 292
openfire_4_6_1.exe 1548
openfire_4_6_1.tar.gz 888 404
openfire_4_6_1_bundledJRE.exe 509
openfire_4_6_1_bundledJRE_x64.exe 2219
openfire_4_6_1_x64.exe 3611
openfire_src_4_6_1.tar.gz 126 25

Please report any issues in the community forums or stop on by the online groupchat to let us know how things are going for you. Thanks for your interest in Openfire!

For other release announcements and news follow us on Twitter

2 posts - 2 participants

Read full topic

by akrherz at February 05, 2021 15:01

Push Notification Openfire plugin 0.8.0 released

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

This update fixes a problem that prevented certain clients (like Siskin) from successfully register a push notification service.

Note that, after upgrading the plugin from an older version, Openfire will need to be restarted. This too is caused by a bug, that has been addressed in this new release (but one last restart is needed to remove remnants of the bug that was present in previous versions of the plugin).

As always, your installation of Openfire should automatically detect the availability of the update in the next few hours. Alternatively, visit the plugin archive page to download the plugin directly.

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

by guus at February 05, 2021 09:22

Monal IM

Monal Stats 1/2021

We don’t track the number of users Monal has. We do see thousands of downloads in the App Store statistics. Any user counting and crash tracking provided by Apple is strictly opt in only. So it always undercounts. However because ever user registers a push device with the push server we do see how many devices there are using Monal. This is a very rough estimate that is a bit inflated because you can reset your push deviceids. With all that said, there are currently 61,953 devices registered to receive push notifications. On January 31th the push sever sent 77,199 push notifications. Which comes to just under one a second.

by Anu at February 05, 2021 05:58

Push Outage

There was a push outage for some users today for a few hours. Apple updated their intermediate certificate and it appears to have gone in effect earlier than expected. The new certificate expires in 2030 so this shouldn’t be an issue again. Apologies for the inconvenience.

by Anu at February 05, 2021 05:54

February 02, 2021


February 2021 server release

A year ago, Snikket was first announced publicly, at the FOSDEM conference in Brussels. FOSDEM 2021 is next week, online of course, and I’ll be giving a talk about some of the thoughts that led to me starting the Snikket project.

A year is a long time on the internet! Since that initial announcement we’ve incorporated as a not-for-profit, formalized our goals and made significant progress towards them.

Today that progress continues, as we release the largest update to our self-hosted server software yet! This release includes a web administration dashboard, support for multiple distinct groups of users, and finally… support for Raspberry Pi and other ARM devices.

Admin dashboard

Until now the only way to manage your Snikket server - for example to invite new users or reset passwords - was by using the command-line. That is all about to change, as we now have a lovely web interface to perform all kinds of management tasks!

The Snikket web interface

The dashboard is already translated into multiple languages (currently English, French, German, Italian, Indonesian and Polish).

We also have a simple portal for non-administrative users to log in and manage their account. Currently this contains a profile editor, and will grow to include other account settings, and data import/export.

The user profile editor

This project has been the work of Jonas Schäfer, without whom it wouldn’t have been possible to ship anything quite as extensive or polished by now! Many thanks also to the community members who have contributed the initial translations.

Raspberry Pi and ARM support

We have grown our build infrastructure to include two Raspberry Pi servers, which now provide continous builds for ARM (32-bit and 64-bit) architectures. This means that finally the Snikket Docker images work out of the box on just about any Raspberry Pi device.

Due to the relatively low resource requirements of the Snikket server, and the relative affordability of Raspberry Pi devices, they make a great device to begin your self-hosting journey!


Snikket is designed with small groups of people in mind. Whether your Snikket instance is serving your family, club or workplace, we chose to make contact discovery easier by automatically showing all other users on the same Snikket service in your contact list.

However this could be problematic if you wanted to share the same server across multiple social groups. Maybe you want to invite your gaming buddies to your Snikket server, but without them awkwardly finding all your family members in their contact list.

We have added a new feature which allows you to have multiple groups of people, which we refer to as “circles”. When you create an invitation you can choose which circle to assign the new user(s) to.

If you are upgrading from a previous version of the Snikket server, there will be an initial migration process that automatically moves all users to a new default circle.

Finally, circles have an associated private group chat to which all circle members are invited. This replaces the clunky ‘general’ chat that was created in previous releases.

Other changes

We’ve made some architectural changes in this release. If you’re upgrading from a previous release, make sure you follow the upgrade notes in the changelog.

The file upload limit is now 16MB (the same as WhatsApp’s limit). We are working on allowing even higher limits but with per-user quotas for a future release, to ensure you don’t run out of precious disk space :)

Finally, if you’re setting up Snikket for the first time, we now have a collection of scripts and resources to help you get started, over at snikket-selfhosted!

We’re looking forward to hearing feedback about this release. Let us hear your success stories 😉

A quick reminder that this is an independent open-source project working to provide a free (as in freedom) alternative to proprietary mainstream messaging services. If you benefit from the software we produce, or simply want to support our work, feel free to donate, no matter how small!

by Snikket Team ( at February 02, 2021 12:45

February 01, 2021


Kaidan 0.7 released

This release enables the users to send files via drag and drop. Furthermore, it is possible to see which chat client and operating system a contact is using. Additionally, newlines can be inserted into a text message with ShiftEnter now. We are working on some major features such as message history synchronization (MAM) and typing notifications. They are nearly finished and we hope to ship them in Kaidan 0.8 very soon™.

Drag’n’drop for files


These are the new features of the release:

  • Display client information (name, version, OS) of contacts (jbb, lnj)
  • Drag’n’drop for sending files (jbb)
  • Allow pasting images from the clipboard (Ctrl+Shift+V) into the chat (jbb)
  • Allow inserting newlines using Shift+Enter (jbb)
  • Add configuration of custom hostname/port (jbb, melvo)
  • Favourite emojis are shown by default now (melvo)
  • Search emojis by “:" (melvo)
  • Display connection errors in the global drawer after login (melvo)
  • Improved design of media preview sheets (jbb)
  • Restructure message sending bar (melvo)

And the following bugs have been fixed:

  • Do not interpret random URLs as files anymore (lnj)
  • Fix the style of buttons when using Material style (melvo)
  • Fix file dialog and media drawer opening in some cases (melvo)
  • Fix opening of the login page when scanning QR code without password (melvo)

Note: Kaidan requires Qt 5.14 now.


Or install Kaidan from your distribution:

Packaging status

February 01, 2021 23:00

January 31, 2021

Monal IM


We urge you to update to Monal ≥ 4.9 if you haven’t done it yet.

We discovered a security bug in Monal < 4.9 dubbed CVE-2020-26547:

Monal before 4.9 does not implement proper sender verification on MAM and Message Carbon (XEP-0280) results. This allows a remote attacker
(able to send stanzas to a victim) to inject arbitrary messages into
the local history, with full control over the sender and receiver displayed
to the victim.


Thilo and Friedrich

by Thilo at January 31, 2021 08:02

Wanted: Monal feedback

Hi fellow Monal-Beta users,

we were asked to post an update of our development journey for the next xmpp summit.
Because we as the developers of the monal beta are way too proud of our own achievements,
we ask you as the community to provide a more realistic view of the monal project.

Can you write a (really) short paragraph about where the project started when you first used it,
where it is now (if you are still using it ;)) and what improved or not improved over the past year.
What are the things you are most happy with? What upcoming things do you await most eagerly?

Please submit your user stories as blog comment or in the monal groupchat until 2021-02-03 (YYYY-MM-DD).

If you want, just add your name below the text and we’ll publish it along the text (or leave it out to get published anonymously).

Thank you very much for the last year full of debugging builds with us!
Anu, Emus, Friedrich, Jim, Thilo

by Thilo at January 31, 2021 06:55

January 28, 2021

The XMPP Standards Foundation

Messagerie instantanée : Il ne s'agit pas de l'application

This is the French translation of the original blog post. Cet article est la traduction française de l'article original du blog. Thanks to anubis, mathieui, nÿco, pmaziere, pulkomandy and ysabeau for their translation and review!

Autres traductions : - Deutsch - Español - Română

Parce qu’elles ne comprennent pas les critères à prendre en compte pour le choix d’un type de messagerie instantanée, plusieurs personnes m’ont récemment contacté pour me demander lequel ils devraient utiliser et si elles devraient migrer d’une des solutions ayant pignon sur rue à une autre du même acabit. Je me suis demandé comment répondre à ces questions. Évidemment, j’aurais simplement pu plaider pour XMPP (Extensible Messaging and Presence Protocol), mais j’ai pensé que cela ne serait peut-être pas une réponse utile en soi. Souvent, les gens prennent une décision rapide concernant leur logiciel de communication, et ce n’est généralement pas un choix bien réfléchi, ce qui, plus tard, les amènera inexorablement à passer à une autre messagerie instantanée.

Beaucoup ne feront en fait qu’ajouter une autre messagerie instantanée à leur collection toujours croissante de messageries, ce qui est probablement plus frustrant qu’utile. Cela me ramène à la question initiale : quel enjeu et quel problème veut-on résoudre ici ? Quelles sont leurs motivations ? Peut-on trouver une solution avec un meilleur fondement technologique qui évite l’effet de mode et n’implique pas l’installation de plusieurs applications de messagerie ?

Il y a autant de réponses que de personnes qui posent ces questions : quand certains ont besoin d’une réelle protection de leurs données personnelles, les autres demandent un contrôle complet sur celles-ci, ou s’attendent simplement à pouvoir joindre tous leurs contacts à partir du même appareil. Quelles que soient ces attentes, migrer d’un système de messagerie à un autre implique souvent de laisser certains contacts derrière soi. De nombreux systèmes de messagerie ont en plus fait le choix de réclamer un numéro de téléphone, ce qui n’est pas un bon point de départ pour la protection des données personnelles.

Maîtrise de vos communications

Comme vous vous en doutiez, je vais recommander XMPP. Je pense que la première chose à faire n’est pas de choisir une application de messagerie, mais de choisir la technologie logicielle sous-jacente. Réfléchissons d’abord à la technologie avant de sauter d’une recommandation à l’autre.

XMPP est un protocole ouvert, comme HTTP pour le web. L’apparence de votre site web n’a pas d’importance, tout le monde peut interagir avec. L’idée derrière XMPP, c’est d’appliquer le même principe à la messagerie instantanée.

La XSF, ainsi que beaucoup de personnes impliquées dans cette technologie libre, pense que XMPP est un excellent choix d’un point de vue technique, et pas seulement en ce qui concerne la protection des données personnelles. XMPP existe depuis plus de 20 ans, ce qui a permis d’accumuler beaucoup d’expérience de terrain. Cela inclut de nombreux indicateurs clés pour le choix d’une technologie de communication maitrisée, puisqu’il prend en charge :

  • la décentralisation des services de communication (fédération) ;
  • la standardisation et l’extensibilité de la technologie ;
  • l’interopérabilité ;
  • l’innovation par la mise en place d’un développement ouvert ;
  • la protection et le contrôle des données personnelles, incluant le chiffrement de bout en bout.

XMPP fournit les éléments d’information permettant de gérer la communication dans un réseau. Mais chaque personne décide du logiciel client qui lui convient, et sur quel serveur ses données doivent être stockées.

Contrairement à la situation actuelle, où d’autres gens vous incitent à utiliser leur application préférée, dans l’univers d’XMPP vous avez le choix entre de nombreux clients de messagerie : choisissez celui qui vous plaît aujourd’hui, indépendamment des effets de mode, quitte à en changer plus tard. À la différence d’autres technologies de communication, peu importe l’application que vous utilisez ou le serveur qui héberge vos données, vous resterez toujours sur le même réseau que vos contacts. Je pense que c’est une vraie solution.

Ce n’est pas une question d’applications, mais de technologie

Décidez-vous sur la technologie que vous prévoyez d’utiliser, et sélectionnez ensuite quel logiciel correspond à votre usage ou à votre environnement. XMPP et sa communauté ont accumulé une grande variété d’expérimentations qui ont été mises en pratique dans un grand nombre de logiciels. Nous pensons que c’est une bonne solution pour la plupart des individus et des organisations, ainsi que pour la cohérence d’Internet comme un tout, sans compter qu’elle reste ouverte à de futures innovations sans en limiter l’origine.

En plus d’un large choix de logiciels de messagerie, XMPP propose également plusieurs serveurs et outils de développement pour construire vos propres infrastructures.

Il n’y a pas qu’une seule manière de concevoir des applications de communication. Faites le choix d’une technologie standardisée qui restera valable à long terme : pour cette raison, et pour beaucoup d’autres, nous recommandons l’utilisation d’XMPP!

Si vous avez l’intention de choisir une solution pour la prochaine décennie, laissez-moi vous orienter vers plus de documentations :

Cet article de blog est publié sous licence CC BY-SA 4.0.

by Edward Maurer at January 28, 2021 21:40

Mesagerie instantanee: Nu este vorba despre aplicație

This is the Romanian translation of the original blog post. Aceasta este traducerea în limba română a postării originale de pe blog.
Thanks for reviewing Licaon_Kter!

Alte traduceri:

Mai multe persoane m-au contactat recent întrebându-mă ce fel de aplicație de mesagerie ar trebui să folosească acum - au spus că de fapt nu înțeleg despre ce ar trebui să fie preocupați și dacă ar trebui să treacă de la una dintre cele cunoscute la alta. M-am gândit cum să răspund. Evident, aș fi putut pleda pur și simplu pentru XMPP (Extensible Messaging and Presence = Protocolul Extensibil de Mesagerie și Prezență), dar apoi m-am gândit că acest lucru ar putea să nu fie un răspuns util în sine. Adesea, oamenii iau o decizie rapidă cu privire la programele lor de comunicare și de obicei aceasta nu este o alegere întemeiată; și astfel vor ajunge să treacă la o altă mesagerie mai târziu.

Mulți vor adăuga de fapt o altă aplicație de mesagerie la colecția lor tot mai mare, ceea ce este probabil mai mult frustrant decât util. Acest lucru mă aduce înapoi la întrebarea inițială: Ce problemă se dorește a se rezolva? Care sunt stimulentele? Se poate găsi o soluție cu o bază tehnologică mai bună care să evite exacerbările mediatice și nu implică instalarea mai multor sisteme de mesagerie?

Diferite persoane au considerații diferite pentru a răspunde la această întrebare - unele necesită confidențialitatea efectivă a datelor sau suveranitatea datelor sau pur și simplu abilitatea de a avea acces la toate contactele lor dintr-un singur loc. Cu toate acestea, trecerea de la un sistem de mesagerie la altul va însemna adesea lăsarea în urmă a unor contacte. Multe sisteme de mesagerie necesită, de asemenea, un număr de telefon, ceea ce nu este ceva grozav pentru intimitate.

Suveranitatea comunicării

După cum ați suspectat deja, voi pleda pentru XMPP. Cred că prima alegere pe care ar trebui să o facem nu este ce aplicație de mesagerie să folosim, ci ce tehnologie e la baza ei. Luați în considerare mai întâi alegerea tehnologiei, înainte de a trece de la o recomandare la alta.

XMPP este un protocol deschis, la fel ca HTTP pentru Internet. Nu contează cum arată site-ul dumneavoastră, toată lumea poate interacționa cu acesta. Acest principiu este ideea din spatele XMPP, dar pentru mesagerie instantanee.

La XMPP Standards Foundation și împreună cu mulți alții implicați în această tehnologie deschisă, credem că XMPP este o alegere excelentă ca tehnologie de comunicare, nu doar în ceea ce privește confidențialitatea datelor. XMPP există de peste douăzeci de ani și multă experiență practică a fost adunată în tot acest timp. Aceasta include mulți indicatori cheie pentru alegerea tehnologiei și care permite suveranitatea comunicării, deoarece susține:

  • Descentralizarea serviciilor de comunicații (federație)
  • Standardizarea și extensibilitatea tehnologiei
  • Interoperabilitate
  • Inovația și utilizarea dezvoltării deschise
  • Confidențialitatea și controlul, de asemenea, prin utilizarea criptării de la un capăt la altul

XMPP oferă informații bine definite despre cum să fie gestionată comunicarea într-o rețea. Utilizatorul decide ce program de mesagerie i se potrivește sau unde ar trebui stocate datele.

Spre deosebire de situația actuală în care alte persoane vă sugerează să utilizați aplicația sistemului lor preferat, în universul XMPP aveți libertatea de a vă alege aplicația de mesagerie dintre multe opțiuni - alegeți-o pe cea care vă place, nu cea aleasă de ceilalți ca moftul zilei citit pe Internet. Diferența este că, indiferent de aplicația dumneavoastră de mesagerie sau de cea a prietenilor voștrii, aveți în continuare confortul de a vă afla în aceeași rețea cu toate contactele voastre, indiferent de alegerea de astăzi. Cred că aceasta este o soluție reală.

Nu este vorba despre aplicație, ci despre tehnologie

În decizie luați în considerare tehnologia pe care intenționați să o utilizați, și apoi decideți ce aplicație de mesagerie vi se potrivește dumneavoastră sau mediului vostru. XMPP și comunitatea sa au acumulat o experiență variată, care a fost cu succes utilizată într-o mulțime de programe. Credem că aceasta este o soluție bună pentru majoritatea oamenilor și a organizațiilor de pretutindeni și pentru Internet în ansamblu - și este accesibilă pentru noi toți ca să inovăm în viitor.

XMPP are nu doar o gamă largă de aplicații de mesagerie; există, de asemenea, diverse programe pentru server și instrumentele (bibliotecile) pentru a vă construi singuri infrastructura.

Nu există un singur mod în care aplicațiile de comunicare trebuie să fie proiectate. Luați o decizie durabilă pentru o tehnologie standardizată - în acest scop, și multe altele, vă recomandăm utilizarea XMPP!

Dacă sunteți interesați să faceți o alegere pentru următorul deceniu, permiteți-mi să vă îndrum spre lectură suplimentară:

Această postare pe blog este publicată sub licența CC BY-SA 4.0.

by Edward Maurer at January 28, 2021 21:40

Mensajería instantánea: No se trata de la aplicación

This is the Spanish translation of the original blog post. Esta es la traducción al español de la entrada original del blog. Muchas gracias a Alejandra Pulido por la corrección.

Otras traducciones:

Recientemente, varias personas se han puesto en contacto conmigo para preguntarme qué tipo de mensajería instantánea deberían utilizar ahora; me han dicho que, en realidad, no entienden de qué deberían preocuparse y si deberían cambiar de uno de los proveedores de mensajería instantánea comúnmente conocidos a otro. Me pregunté cómo responder a esto. Obviamente, podría haber defendido simplemente el XMPP (Extensible Messaging and Presence Protocol), pero entonces pensé que esto podría no ser una respuesta útil por sí misma. A menudo, la gente toma una decisión rápida sobre su software de comunicación y ésta no suele ser una elección bien fundamentada, por lo que acabará cambiando a otro proveedor más adelante.

De hecho, muchos añadirán otra aplicación de mensajería instantánea a su creciente colección de aplicaciones, lo que probablemente sea más frustrante que útil. Esto me lleva de nuevo a la pregunta original: ¿Qué pregunta o qué problema se quiere resolver aquí? ¿Cuáles son los incentivos? ¿Se puede encontrar una solución con una mejor base tecnológica que evite el bombardeo y no implique la instalación de múltiples aplicaciones de mensajería?

Cada persona tiene sus propias consideraciones para responder a esta pregunta: algunos requieren una privacidad efectiva de los datos, o la soberanía de los mismos, o simplemente la posibilidad de llegar a todos sus contactos desde un solo lugar. Sin embargo, pasar de un sistema de mensajería a otro suele significar dejar atrás algunos contactos. Muchos sistemas de mensajería instantánea también requieren un número de teléfono, lo que no es bueno para la privacidad.

Soberanía de la comunicación

Como habrás sospechado, abogaré por el XMPP. Creo que la primera elección que hay que hacer no es la aplicación de mensajería a utilizar, sino qué tecnología de software subyacente. Considera primero la elección de la tecnología, antes de saltar de una recomendación a otra.

XMPP es un protocolo abierto, como HTTP lo es para la web. No importa el aspecto de su sitio web, todo el mundo puede interactuar con él. Este principio es la idea detrás de XMPP, pero para la mensajería instantánea.

En la Fundación de Estándares XMPP, y con muchos otros implicados en esta tecnología abierta, pensamos que XMPP es una gran elección como tecnología de comunicación, no sólo en lo que respecta a la privacidad de los datos. XMPP existe desde hace más de veinte años, y en ese tiempo se ha acumulado mucha experiencia práctica. Esto incluye muchos indicadores clave para la elección de la tecnología y la habilitación de la soberanía de la comunicación, ya que apoya

  • Descentralización de los servicios de comunicación (federación)
  • Estandarización y extensibilidad de la tecnología
  • Interoperabilidad
  • La innovación y el uso del desarrollo abierto
  • Privacidad y control, también mediante el uso de la encriptación de extremo a extremo

XMPP proporciona información definida sobre cómo manejar la comunicación en una red. El usuario decide qué software de mensajería le conviene o dónde deben almacenarse los datos.

A diferencia de la situación actual, en la que los demás te sugieren que utilices su aplicación preferida, en el universo XMPP tu puedes elegir libremente entre muchas aplicaciones de mensajería instantánea: escoge el que más te guste, no el que le guste a los demás hasta la próxima moda de Internet. La diferencia es que, independientemente de la aplicación de mensajería que utilices o de la que usen tus amigos, sigues teniendo la comodidad de estar en la misma red con todos tus contactos, independientemente de tu elección actual. Creo que esta es una solución real.

No se trata de la aplicación sino de la tecnología

Considera la posibilidad de tomar una decisión sobre la tecnología que pretendes utilizar y, a continuación, decide qué aplicación de mensajería instantánea te conviene a ti o a tu entorno. XMPP y su comunidad han acumulado una gran experiencia, que ha sido utilizada con éxito en una gran cantidad de software. Creemos que es una buena solución para la mayoría de las personas y organizaciones que existen, así como para Internet en general, y está abierto a que todos hagamos innovaciones para el futuro.

XMPP no sólo cuenta con una amplia gama de software de mensajería instantánea; también hay varios software de servidor y las herramientas (bibliotecas) para construir la infraestructura por ti mismo.

No hay una única manera de diseñar aplicaciones de comunicación. Decídete de forma sostenible por una tecnología estandarizada - para ese propósito, y muchos más, ¡recomendamos el uso de XMPP!

Si estás interesado en tomar una decisión para la próxima década, permíteme indicarte algunas lecturas adicionales:

Esta entrada del blog se publica bajo la licencia CC BY-SA 4.0.

by Edward Maurer at January 28, 2021 21:40

Instant Messaging: Es geht nicht um die App

This is the German translation of the original blog post. Dies ist die deutsche Übersetzung des ursprünglichen Blogeintrags. Vielen Dank für die Korrekturlesung Daniel Brötzmann, Martin und Paul Schaub!

Andere Übersetzungen: - Español - Française - Română

Kürzlich haben sich mehrere Leute bei mir gemeldet und gefragt, welche Art von Messenger sie jetzt verwenden sollten - sie sagten, dass ihnen nicht klar sei, worauf sie achten sollten und ob sie von einem der allgemein bekannten Messenger zu einem anderen wechseln sollten. Ich fragte mich, wie ich dies beantworten sollte. Natürlich hätte ich einfach für XMPP (Extensible Messaging and Presence Protocol) plädieren können, aber dann dachte ich, dass diese Antwort allein vielleicht nicht hilfreich sei. Bei der Wahl ihrer Kommunikationssoftware treffen Menschen oft sehr schnelle Entscheidungen, die selten gut überlegt und fundiert sind; und so werden sie wohl erneut zu einem anderen Messenger wechseln.

Viele fügen sogar einen weiteren Messenger zu ihrem stetig wachsenden Repertoir von Messengern hinzu, was wahrscheinlich eher frustrierend als hilfreich ist. Das bringt mich zurück zur ursprünglichen Fragestellung: Welches Problem will man hier lösen? Was sind die Absichten? Kann man eine Lösung mit einer besseren technologischen Basis finden, die nicht bloß dem Hype hinterher rennt und bei der man nicht mehrere Messenger-Apps installieren muss?

Verschiedene Menschen haben unterschiedliche Überlegungen zur Beantwortung dieser Frage - manche benötigen einen effektiven Datenschutz, andere Datenhoheit oder einfach die Möglichkeit, alle ihre Kontakte von einem Ort aus zu erreichen. Der Wechsel von einem Messaging-System zu einem anderen bedeutet jedoch oft, einige Kontakte zurückzulassen. Viele Messaging-Systeme erfordern außerdem eine Telefonnummer, was für den Datenschutz kritisch zu betrachten ist.

Souveränität der Kommunikation

Wie vielleicht schon vermutet, werde ich für XMPP plädieren. Ich denke, die erste zu treffende Entscheidung sollte nicht sein, welchen Messenger man verwendet, sondern welche zugrundeliegende Software-Technologie. Man sollte zunächst der Wahl der Technologie betrachten, bevor man von einer Messenger-Empfehlung zur nächsten springt.

XMPP ist ein offenes Protokoll, so wie es HTTP für das Web ist. Es spielt keine Rolle, wie die Webseite aussieht, dank des HTTP Protokolls kann man beliebige Browser wählen um mit ihr zu interagieren. Dieses Prinzip ist auch die Idee hinter XMPP, allerdings für Instant Messaging.

Bei der XMPP Standards Foundation und bei vielen anderen, die an dieser offenen Technologie beteiligt sind, sind wir der Meinung, dass XMPP als Kommunikationstechnologie gute Wahl ist, und das nicht nur in Hinblick auf Datenschutz. XMPP gibt es seit über zwanzig Jahren und in dieser Zeit wurde eine Menge praktischer Erfahrung gesammelt. Dazu gehören viele Kriterien und Indikatoren, die sich als wertvoll für eine fundierte Wahl der Technologie und Ermöglichung von digitaler Souveränität herauskristalisiert haben. Dazu gehören:

  • Dezentralisierung von Kommunikationsdiensten (Föderation)
  • Standardisierung und Erweiterbarkeit der Technologie
  • Interoperabilität
  • Innovation und der Einsatz offener Entwicklung
  • Privatsphäre und Kontrolle, auch durch den Einsatz von Ende-zu-Ende-Verschlüsselung

XMPP stellt definierte Informationen zur Verfügung, wie die Kommunikation in einem Netzwerk abgewickelt werden soll. Der Anwender entscheidet, welche Software er nutzen möchte und wo die Daten gespeichert werden sollen.

Im Gegensatz zur aktuellen Situation, in der andere einem ihren bevorzugten Messenger vorschlagen, hat man im XMPP-Universum die freie Wahl aus vielen Messengern. Jeder kann den Messenger wählen der ihm gefällt, nicht den, den andere mögen und der bei der nächsten Internet-Modeerscheinung wieder ausgetauscht wird. Der Unterschied ist, dass man unabhängig davon, welche Messaging-App man verwendet oder welche App die Freunde benutzen, immer noch den Komfort haben, mit all seinen Kontakten im selben Netzwerk zu sein, unabhängig von der heutigen Wahl. Ich denke, das ist eine echte Lösung.

Es geht nicht um die App, sondern um die Technologie

Man überlegt sich, welche Technologie man einsetzen will, und entscheidet dann, welcher Messenger zu einem selbst oder seiner Umgebung passt. XMPP und seine Community kann auf eine große Menge Erfahrungen zurückgreifen, die erfolgreich in einer Vielzahl von Anwendungen umgesetzt werden. Wir sind der Meinung, dass dies eine gute Lösung für die meisten Menschen und Organisationen da draußen sowie das Internet als Ganzes sein kann - und es ist offen für uns alle, um Innovationen für die Zukunft zu ermöglichen.

XMPP hat nicht nur eine breite Palette an Messaging-Software, es gibt auch verschiedene Server-Software und Werkzeuge (Bibliotheken), um die Infrastruktur selbst aufzubauen.

Es gibt nicht die eine Art, wie Kommunikations-Apps gestaltet werden müssen. Man kann sich nachhaltig für eine standardisierte Technologie entscheiden - dafür und für viele andere Zwecke empfehlen wir den Einsatz von XMPP!

Wenn der Text Interesse geweckt hat, eine Entscheidung für das nächste Jahrzehnt zu treffen, möchte ich auf diese weiterführende Lektüre hinweisen:

Dieser Blogbeitrag ist unter der CC BY-SA 4.0 Lizenz veröffentlicht.

by Edward Maurer at January 28, 2021 21:40


Development News January 2021

Gajim 1.3.0 is almost there and Gajim’s XMPP library python-nbxmpp had its 2.0.0 release! This month brings many bugfixes and a long anticipated feature: direct chat messages for private group chats.

Changes in Gajim

The first month of 2021 was mostly about bug fixing in preparation of the upcoming 1.3.0 release. Also, Gajim joined Fosstodon this month! 🎉

Gajim will now use direct messages in non-anonymous group chats instead of Private Messages (which would be routed through the group chat). This behavior is of course configurable, but the new default will reduce confusion significantly: If you start a chat with a group chat participant of a private group chat, Gajim will open a chat addressed directly to the participant.

What else happened

  • Added new debug mode: start gajim with --gdebug to see GLib debug messages
  • Bugfixes for the new profile window
  • Fixed race condition while removing an account #10401
  • Fixed issue with clipboard being cleared accidentally after pressing Alt+Tab
  • Bugfix for an error which occurred when closing the chat window while being in a call
  • Fixed History Manager’s stand-alone mode #10384
  • Bugfix for tooltip error occurring with empty PEP info #10235

Plugin updates

Gajim’s Client Icons plugin enables you to see which chat client(s) your contact is using, by displaying the client’s name and icon. This month, (a popular Conversations fork) has been added, and detection for both Movim and PSI+ has been improved.

Changes in python-nbxmpp

python-nbxmpp 2.0.0 has been released, featuring JID Escaping (XEP-0106), VCard4 (XEP-0292), and GSSAPI (XEP-0233) support. As covered in previous posts, module calls are now based on Python Generators. Furthermore, the module API has been simplified and harmonized.

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


January 28, 2021 00:00

January 26, 2021

Monal IM

Monal 5.0 will be the last version to support ios12

We like to support things as long as we can. However, eventually we do see the need to drop older os support so we can focus efforts on current versions. The long life of Apple devices means we end up supporting very old hardware for a long time. For example, we still support the iPad mini 2 from 2013 running ios12. Thankfully apple also provides OS updates for a long time and everyone upgrades. There are actually a very small number of devices from 7-8 years ago that run iOS 12 but not 13 or 14. We are dropping support for these devices after the next release because ios12 is different enough that it needs a different push server and code and has increasingly required special debugging to deal with differences in the way the os works. It appears there are now only 24 ios12 devices actively using Monal. Apple stats are opt in only so there are definitely more but this number will still be much much smaller than the thousands more using iOS 13 and 14.

by Anu at January 26, 2021 13:40

Mac 4.9 is out

App Store issues have been resolved. 4.9 is out on the Mac. I don’t expect the iOS and Mac releases to be out of synch again

by Anu at January 26, 2021 05:37

January 24, 2021

Monal IM

Update on Mac App Store release

We have identified the cause of the crash that was causing Apple to reject Monal when submitted to the Mac App Store. The root cause of the problem was the behavior of action sheet type of alerts. This was changed from a Mac style alert in Catalyst running on Catalina to the iPad popup style in Big Sur. This resulted in the OS expecting x/y coordinates for the origin of the popup and crashing. The plus side of Apple hardware is that it lasts forever. My mac mini is from 2011 and my Macbook is from 2010. With enough RAM and an SSD there wasn’t actually much of a reason to upgrade. Unfortunately, none of my machines can run Big Sur well now (even with with the hacks I use to run on unsupported hardware ) and I’ve purchased an M1 mini as a replacement. If anyone has tried to get a computer during the pandemic you know it involves waiting. I have a working solution for Big Sur while I wait for my new machine to arrive in mid Feb. This should let us catch issues in Catalina and Big Sur and prevent this from happening again.

by Anu at January 24, 2021 03:39