Gajim 1.5.2 brings another performance boost, better emojis, improvements for group chat moderators, and many bug fixes. Thank you for all your contributions!

What’s New

Generating performance profiles for Gajim revealed some bottlenecks in Gajim’s code. After fixing these, switching chats should now feel snappier than before.

Did you know that you can use shortcodes for typing emojis? Typing :+1 for example will open a popup with emojis to choose from. Now there are even more shortcodes waiting for you. Also, emojis combined by ZJW sequences are now rendered correctly, if they are used for workspace icons.

This release comes with an improvement for admins and moderators of group chats as well: You can now right-click the profile picture of any participant to reach moderation tools.

There has been a bug where messages sent by you would not show under certain circumstances. Various users chimed in to help fixing this bug by reporting under which circumstances it would appear. Thanks for your help!

More Changes

New

• Support for HEIF image previews
• Server info dialog now shows TLS version and cipher used for your connection
• For developers: Gajim now offers a content viewer PEP nodes

Changes

• Hotkey for re-opening closed chats: Ctrl+Shift+W
• Gajim now highlights areas where you can drop chats or workspaces

Fixes

• Nickname suggestions in group chats should yield better results now
• Text in right-to-left languages is now aligned correctly
• Notifications for group chat messages have been fixed

Over 20 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 gajim@conference.gajim.org or open an issue on our Gitlab .

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of September 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):

• English (original): xmpp.org
• French: jabberfr.org and linuxfr.org
• German: xmpp.org and anoxinon.de
• Italian: nicfab.it
• Spanish: xmpp.org

XSF Announcements

• The XSF membership application period for the fourth quarter 2022 is currently open. If you are interested in becoming a XSF member then you can apply for membership . Please submit by November 27, 2022.

• The XSF Board and Council application period for the next year is currently open. If you are interested in running for the XSF Board or XSF Council then you can apply here . Please submit by November 6, 2022. Remind that XMPP Council members must be elected members of the XSF; however, there is no such restriction for the Board of Directors.

• Security advisory: libexpat before 2.4.9 is vulnerable to CVE-2022-40674 , make sure to update, if you depend on it.

Google Summer of Code 2022

The Google Summer of Code 2022 finished! The two new contributors Patiga and PawBud were working on open-source software projects in the XMPP environment. Read their all their blog posts, too. Thanks everyone for participation!

• Patiga worked on more flexible file transfers in Dino . Mentors are fiaxh and Marvin W. .

  • Stateless File Sharing GSoC project
  • Project Stateless File Sharing: First Steps
  • Stateless File Sharing: Base implementation
  • Stateless File Sharing: Sources and Compatibility
  • Stateless File Sharing: Async, Metadata with Thumbnails and some UI

• PawBud worked towards adding support for A/V communication via Jingle in ConverseJS . Mentors are JC Brand and vanitasvitae .

  • On-Boarding Experience with XSF (Converse)
  • ConverseJS: An in-depth view into my GSoC'22 project!
  • Google Summer of Code 2022 at XSF: Converse.js - Mid Term Evaluation Update

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:

• Bifrost bridge: Offline messages exchange between Matrix and XMPP
• Mellium Co-op

Events

• XMPP Office Hours : available on our YouTube channel
• Berlin XMPP Meetup (remote) : monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month
• Capitole du Libre : Members of the “JabberFR” and “Libre en Communs” associations will be present in Toulouse on the 19-20th of November

Articles

Congrats to the Monal developers for the new NLnet Funding that will cover privacy enhancements for the push servers, an explorative audio and video calls implementation, UI updates for MUC and Contact views, and SASL updates.

Paul Schaub wrote a blog post focused on the technical details of how to check the validity of nested packet sequences using pushdown automata. This technique will be used in a partial rework of PGPainless to validate OpenPGP messages. Earlier this month another post on “Creating a Web-of-Trust Implementation: Accessing Certificate Stores” has been published, too.

jmp.chat brought voicemail changes and opt-in Jabber ID discoverability to their service, along with an updated Android app and new custom F-Droid repos for both stable and pre-release versions. Furthermore, they wrote about “Privacy and Threat Modelling” in general.

Arnaud wrote about updates on the chatty server and HTTPAuthentificationOverXMPP .

Anoxinon.media published their blogpost XMPP - Teil 1 - Messaging mal anders [DE].

Software news

Clients and applications

Maintenance release of Beagle IM 5.3.1 that fixes sending OMEMO encrypted files and entering password-protected MUC. Besides, Tigase launched a new, simpler website tigase.org that makes it easier to access open-source projects created by Tigase.

Gajim 1.5.0 and 1.5.1 have been released . These releases come with a significant performance boost. Pinned chats can be ordered via drag and drop, message corrections have been improved, and many bugs have been fixed.

An OMEMO 2 implementation has just been merged to Libervia , coming with Stanza Content Encryption ( XEP-0420 ) support, thanks to the great work of Syndace, author or python-omemo (which has been updated in the process). One of the major benefits is that other Stanza elements can now be encrypted too, not only the body. OX ( XEP-0373 / XEP-0374 ) should follow soon, exciting times!

While Monal development is going forward, see the funding news above, and they deployed new Push servers as announced in the July 2022 XMPP Newsletter, users of old Monal versions would need to update, so if you or your contacts didn’t already the developers urge you to do it now .

Missed in the August 2022 XMPP Newsletter was a release of UWPX, the XMPP client for UWP (Windows 10) devices. While version v.0.43.0.0 has only a fixup it’s unfortunately also the Final Update as the developer is stepping away from the project. Maintainers to follow-up are welcome to reach out!

Kaidan, a user-friendly and modern chat app for every device, will receive a grant by NLnet for adding encrypted audio and video calls . Congratulations!

Servers

Jackal v0.62.0 is out bringing XEP-0313 Message Archive Management support and several enhancements.

Metronome IM 4.0 has been released . This version introduces Lua 5.3 support, a revamped shared API for group chats stanza archiving, MIX Core/PAM experimental support, Message Moderation support and support for containerization.

Profanity 0.13.0 has been released.

Libraries & Tools

python-nbxmpp 3.2.2 and 3.2.3 have been released , adding a stringprep implementation and improvements for detecting broken TCP connections.

The first beta of Slidge (XMPP bridges) is out!: Slidge, supporting Signal, Telegram, Discord, Steam, Mattermost, Facebook and Skype. Currently only direct messages are supported, but development is going further. Find the article in English and French .

Work on XMPP ⇔ ActivityPub gateway (supported by a NLnel funding) has been achieved. The gateway supports features such as following/followers, favourite/like (or “noticed” in XMPP terms , reactions (compatible with Pleroma ), mentions, sharing/reboost and lastly events (compatible with Mobilizon ). It has been tested with Mastodon , Pleroma and Mobilizon. It’s still considered alpha quality, a blog post should follow soon to explain in more details .

Ignite Realtime Community:

• REST API Openfire plugin 1.10.0 has been released
• New Openfire plugin: Push Server

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 ).

xmpp.org features a page about XMPP RFCs as well.

Proposed

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.

• Events
  • This specification describes how to handle calendar events with XMPP

New

• No new XEP this month.

Deferred

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.

Updated

• Version 0.4.0 of XEP-0440 (SASL Channel-Binding Type Capability)
  • Make sasl-channel-binding element a top level stream feature (dg)

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 can help improve the XEP before returning it to the Council for advancement to Stable.

• No Last Call this month.

Stable

• No XEP moved to stable this month.

Deprecated

• 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:

• Mastodon
• Twitter
• YouTube
• Lemmy instance
• Reddit
• LinkedIn

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), alkino, anubis, Benoît Sibaud, emus, goffi, Jeybe, Licaon_Kter, martin, MattJ, MSavoritias (fae,ve), nicfab, Ppjet6, vanitasvitae, 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

License

This newsletter is published under CC BY-SA license .

Gajim 1.5.0 and 1.5.1 come with a significant performance boost. Pinned chats can be ordered via drag and drop, message corrections have been improved, and many bugs have been fixed.

What’s New

For many years, Gajim’s internal handling of how a chat is loaded and displayed hasn’t changed. Each chat would create a new Control , which would hold the chat banner (name, chat state, etc.), the conversation view (messages), and a message input, including actions and menus. This approach does not scale well, since Gajim’s resource usage would increase with every new chat. With Gajim 1.4, we introduced a new conversation view, which increases the overall number of elements being displayed at the same time. Multiply this by the number of open chats, and you’ll get a lot more elements, which have to be rendered all at once. Due to some GTK theming issues (looking at you, backdrop animation), every focus/defocus of Gajim would lead to a spike in CPU usage.

To overcome these limitations, we changed Gajim’s fundamentals. The whole chat window with all its elements is now created only once, and then shared between all chats. Gajim just switches each element’s state when switching chats. Due to a drastically reduced amount of elements being loaded, this change alone reduces Gajim’s RAM usage by 20 %. With less elements being rendered at once, the delay ‘from click to action’ is also significantly reduced. In other words: Using Gajim feels more snappy.

More Changes

New

• Drag and drop for ordering pinned chats
• Use Ctrl+Number to switch between workspaces
• The chat list can now be toggled using a button or Ctrl+R

Changes

• Chat command system has been reworked
• Message corrections are now available from the message menu
• Windows: Overall text size has been increased
• Ctrl+F replaces Ctrl+H for opening the search bar
• Advanced Configuration Editor (ACE): non-default settings are highlighted
• Syntax highlighting for the XML console’s input
• IPython support has been removed

Fixes

Over 40 issues have been fixed in this release.

Due to a bug found shortly after releasing Gajim 1.5.0, it was necessary to release Gajim 1.5.1.

Have a look at the changelog for the complete list.

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

The Ignite Realtime Community is pleased to announce the 1.0.0 release of the Push Server plugin for Openfire. This plugin is developed by the company Busoft Teknoloji A.Ş. It is inspired by Conversations Push Proxy and developed for Openfire.

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

Stop by our support groupchat to get in touch, or leave a message on our community site .

For other release announcements and news follow us on Twitter

What is this plugin for

Due to the restrictions in push services (FCM or APNS), only the developer can create push notifications for their apps. For this reason a user’s server wouldn’t be able to wake up a user’s device directly but has to proxy that wake up signal through the infrastructure of the app developer.

Push Server Plugin is an XEP-0357: Push Notifications app server that relays push messages between the user’s server and FCM (Firebase Cloud Messaging) or APNS (Apple Push Notification Service).

Here is a quick description of how this relationship is set up.

XMPP Client sends to the app server

- Device Token
- Device Id

App Server generates

- Node Id
- Secret

App Server stores

- Device Token
- Device Id
- Node
- Secret

App Server returns to XMPP Client

- Node Id

XMPP Client sends to the user's server

- Node ID
- The jid of the app server (push.example.com)

The user’s server sends to the app server

(Achived by Openfire Push Notification plugin)

When a push is required the user’s server will send the node id to the app server. The user’s server can also add additonal information like number of messages pending, the sender jid of the last message and even the body of the last message.

An example of that communication can be found in XEP-0357 Section 7 .

9 posts - 3 participants

Read full topic

I finally took time to setup a forge and some old drafts turned up. I am publishing one of them today as is even though it’s 4 years old (2018-08-07T13:27:43+01:00). I’m not as grumpy as I was at the time but I still think this applies.

Today I am grumpy at people’s expectation of a free software project, about versioning and releases. I am mostly concerned about applications rather than libraries in this article but I am sure some of this would apply to libraries as well.

Today we were discussing about versioning and releases in the poezio chatroom.

Poezio is a console application, a small project maintained by a handful of contributors to which I am grateful. I also have a few contributions myself. The application is far from perfect but what software is anyway.

The last release – as of writing – for the project is 0.11 , published on Jan 31, 2017. A bit over 1.5 years ago. Yes, the project is still being actively maintained, but no release is being made for the moment.

No , not every project releases with the same regularity. No , not every project has the same understanding of what a release is. Most projects don’t have the same constraints.

For some projects releases are sacred and I am happy for them. Maintained for X months or even years to which will only be applied security fixes or critical bug fixes (crashes and the like).

For others, releases are only checkpoints. A way of saying that features are being added, bugs are being fixed, and have people talk about it.

There is no global definition of what a release is supposed to be. It is up to project maintainers to decide what they want to see in it. They could very well make a release every other commit and be happy with it if they wanted to be silly. They would still be semver compliant – one of the various versioning scheme defined out there.

Nothing also mandates they have to backport bug fixes to the current or previous releases, and some projects actually cannot afford such a luxury. All of this takes time and that is a really expensive resource in a project.

Update from the present:

I think the issue I tried to convey in this article isn’t that we don’t have time, or that there’s no definition of a release, it’s that I’m tired of being imposed a vision of the world I don’t agree with. What’s more, people having these expectations often don’t even take part in the process of making the project or the in community around it, at any level.

It's been a long time since I updated this blog. It will be a short update post about two projects.

chatty_server

The first is chatty_server, a small XMPP bot I use to interact with my server. It allows me to get information about the CPU load, traffic, weather etc. It also has a small feature to get reminder messages. There was a bug that allowed anyone to spam reminders. Anybody can add the bot to their rooster and could create random reminders that I would get. I got none, so the bot must remain quite unheard-of.

HTTPAuthentificationOverXMPP

The second project is HTTPAuthentificationOverXMPP, a component that I use to allow 2 Factor authentication with XMPP. The original project had not been updated for a long time and I wanted to try to modify it to rely on another XMPP go library. I have never coded in Go and it seemed like a nice introduction. I relied on go-xmpp where I added the support for XEP 0070 . It was really interesting. The new component is running for several months and I am quite happy with it even if I don't have any serious project relying on it.

The https://demo.agayon.be/ website is still up if you want to test it.
I hope being able to provide more update about my projects in the future :-).

Links

• XEP-0070
• Authentication component by Chteufleur
• Fork of go-xmpp
• Fork of HTTPAuthentificationOverXMPP
• Chatty Server

We recently started to migrate the App from Anu Pokharel ‘s Apple account to Thilo Molitor ‘s Apple account.

As part of this transition we also deployed some new push servers to not let an old retired developer pay for the infrastructure needed for Monal.

Coming along with this transition from the old developer team to the new one is our new clean website at https://monal-im.org/ . From now on, this blog will not be used for Monal anymore.

Many thanks to all users, contributors and followers so far.

Special thanks goes to Anu. Without him and his passion, Monal would not have been possible. He developed and maintained Monal for more than 10 years, always ensuring compatibility with the latest iOS releases.

When I (Thilo) gradually took over development, I was able to build upon an app with a decent codebase rather than writing my own app from scratch. That made it possible to improve Monal further while already being used by thousands of people. I can not stress enough how thankful I was and still am for all the work Anu put into the development of Monal.
Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and macOS!

Thilo, Friedrich, Anu

Async

Asynchronous programming is a neat tool, until you work with a foreign project in a foreign language using it. As a messenger, Dino uses lots of asynchronous code, not always though. Usually my progress wasn’t interfered by such instances, but sometimes I had to work around it.

Async in Vala

No surprises here. Functions are annotated with async , and yield expressions that are asynchronous themselves. And you can’t easily call async methods directly in non- async functions.

Creating problems

I had a async function I wanted to call in a synchronous context. For quick prototyping, I wanted to call that function and get the result directly by blocking. However, the furthest I got there was a variable in a function that is only initialized if you access it late enough (wouldn’t recommend). At that point I restructured the code so that the async call would actually be in an async context with a simple yield .

Here a proper introduction to Vala async .

MetadataProvider

With the introduction of the metadata element, more metadata can be extracted from files and attached to file transfers. You wouldn’t have guessed, but there are actually a rather big variety of file types. So not only do different files use different metadata fields, but they can also use the fields in different ways.

To accommodate that relation, the FileManager module now keeps a list of FileMetadataProviders, which will be extended over time. When a file is sent, each provider is asked if it is compatible with the file. If yes, it is called. The first provider is a generic one which is called for every file and fills in name, last-edit-date, size, mime-type and hashes.

Thumbnail creation

A special new field is a list of thumbnails. They are intended for small previews of whichever file it is attached to, be it a image, video or pdf. So far, I have implemented thumbnails for images, which introduced two design decisions.

Size : Which dimensions should the preview have? When it is displayed, it should be stretched to the format of the original image, so the aspect ratio should sort of match. My mentor, larma , suggested that we create very small thumbnails for now, about 8 or 9 pixels. Which dimensions would that allow? 1x8, 2x4, 3x3, 4x2, 8x1. Well, that sounds pretty diverse, no? Those are the dimensions that we use for now, and I select the dimension with the closest aspect ratio.

Scaling : Now that we have the size, how do we scale the image? Luckily, Gtk (which Vala is closely integrated with), has scaling methods for images. So far, I used bilinear scaling, which is usually the suggested method according to the docs. However, scaling to such a small size results in a lot of gray. While you could probably come up with a fancy custom-made algorithm, I’ll stick with the Gtk built-in methods. Maybe nearest-neighbor could be a better choice, because it would show a ’true’ color from the original image.

UI

I tried to hold off on UI work until the last weeks of the projects. While this could’ve easily been due to procrastination (I don’t enjoy UI coding a lot), I actually have a good excuse here. The Dino codebase is being migrated to Gtk4 from Gtk3 this year. Due to this, a lot of UI code is being rewritten, and it would’ve been wasted work to implement new UI elements in the old codebase. The new UI element I introduced is the FilePreviewWidget , which holds a thumbnail of files which are so large that they aren’t immediately downloaded (currently >5 MB). Luckily, the user interaction and graphical components are really close to the FileImageWidget and FileDefaultWidget , so the implementation wasn’t that difficult.

Progress

We are nearly finished. The one thing left is source attaching , which the next (and last) progress post will cover. Like always, you can track my progress on the stateless-file-sharing branch. I also created a pre-gtk4-rebase branch stateless-file-sharing-pre-gtk4 .

Kaidan will receive a grant by NLnet for adding encrypted audio and video calls.

The calls will be end-to-end encrypted and authenticated via OMEMO . Furthermore, Kaidan will support small group calls. We strive for interoperability between Kaidan and other XMPP apps supporting calls. In order to achieve that, we will implement a large number of XEPs (XMPP Extension Protocols). They make it possible to have a modern call experience.

Calls have become more widespread over the past few years in free XMPP chat apps. Especially, grants by NLnet made that possible. The development speed and interoperability between different apps have increased. Such an intense development often results in improved specifications. But sometimes the development overtakes the standardization. In that case, the standardization needs to catch up what has already been implemented.

We have to handle that circumstance with group calls and invitations to calls at the moment. There are some adjustments that are not yet official. To make calls from Kaidan to other apps already supporting them, we have to base our work on those changes. If those unofficial adjustments are being modified later to become official, we will need to modify Kaidan as well. But we see the evolution of calls in XMPP as a huge progress and are ready for adaption!

Kaidan’s goal is to establish free and secure communication while being easy to use , thus lowering the entry barrier to XMPP for average users coming from other networks. NLnet and a couple of other organizations support us via the NGI Zero PET fund to achieve that. The money is provided by the European Commission. That is an example of how software can be developed according to the Public Money, Public Code initiative .

There are many other interesting projects currently funded by NLnet . We are glad that Kaidan is one of them!