In today’s interconnected world, digital sovereignty has become increasingly important for individuals and organizations seeking to maintain control over their data, infrastructure, and technologies. Openfire, an open-source, real-time collaboration (RTC) server that uses the XMPP (Extensible Messaging and Presence Protocol) protocol, offers a secure and customizable communication platform.

About Openfire

Openfire, produced by the IgniteRealtime community, is a mature, robust and scalable XMPP server that facilitates real-time communication and collaboration. It supports a wide range of features, including instant messaging, group chat, voice and video calls, and file sharing. Openfire’s open-source nature and extensive plugin architecture make it a versatile and customizable solution for organizations of all sizes. Openfire’s compatibility with various XMPP clients, including but not limited to IgniteRealtime’s own Pádè and Spark clients, further enhances its versatility and utility.

Data Privacy and Security

One of the key aspects of digital sovereignty is the ability to protect sensitive information and ensure data privacy. Openfire provides a secure communication platform that supports end-to-end encryption, secure authentication, and fine-grained access control. By hosting Openfire in-house or on a private cloud, organizations can maintain control over their communication data and reduce the risk of data breaches or unauthorized access. Additionally, Openfire’s open-source nature allows users to audit the code and verify the security of the platform, further enhancing trust and transparency.

Customization and Flexibility

Openfire offers a high degree of customization and flexibility, enabling organizations to tailor the platform to their specific needs and requirements. With a wide range of plugins and extensions, Openfire can be easily integrated with existing systems and workflows, allowing users to create a communication environment that aligns with their unique processes and preferences. This enables organizations to maintain control over their communication tools and adapt them to their evolving needs.

Compliance and Regulatory Control

Openfire’s customizable and secure nature makes it an ideal platform for organizations operating in regulated industries or jurisdictions with strict data protection laws. By hosting Openfire in-house or on a private cloud, organizations can ensure that their communication data remains within their control and complies with relevant regulations. Furthermore, Openfire’s extensive logging and monitoring capabilities enable users to demonstrate compliance and maintain a clear audit trail of their communication activities.

Interoperability with Other XMPP Solutions

Openfire’s interoperability with other XMPP-based platforms and clients is another significant advantage. By supporting the XMPP protocol, Openfire enables seamless communication and collaboration with users on other XMPP servers and clients, fostering a decentralized and open communication ecosystem. This interoperability allows organizations to maintain control over their communication infrastructure while still being able to connect and collaborate with external partners, customers, or stakeholders. Moreover, Openfire’s compatibility with other XMPP solutions reduces the risk of vendor lock-in and promotes a more open and competitive market for communication tools.

Conclusion

Openfire offers a powerful and secure communication platform that supports digital sovereignty by enabling organizations to maintain control over their data, infrastructure, and technologies. With its robust security features, customization capabilities, compliance-friendly nature, and interoperability with other XMPP solutions like Pádè and Spark, Openfire empowers users to create a communication environment that aligns with their unique needs and requirements. As digital sovereignty continues to gain importance in today’s interconnected world, Openfire provides a valuable solution for organizations seeking to enhance their autonomy, privacy, and security in digital interactions.

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

XMPP Newsletter Banner

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

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, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XSF Announcements

XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, please apply before August 17th, 2025 00:00 UTC.

XMPP Events

• DebConf25: The 26th Debian Conference in Brest, France, from July 14th to 19th 2025, will feature:
  • Federated instant messaging, 100% debianized by Elena Grandi. A short talk (20 minutes) that will take place at the Grand amphi room on Monday, July 14th at 18:00 hours.
  • Jabber/XMPP BoF session, hosted by Martin. A BoF (Birds of a Feather) meeting (45 minutes) that will take place at ‘Room: B03-035’ on monday July 14th at 14:00 hours.
• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM UTC+2 (online event, with web meeting mode and live streaming).

Videos

Comunicación Libre, Segura y Descentralizada: Taller abierto de XMPP by Gnuxero for the Club de Software Libre. [ES]

XMPP Articles

• Introducción a XMPP - Capítulo 1 by Jacobo Da Riva Muñoz. [ES]
• Introducción a XMPP - Capítulo 2 - OMEMO by Jacobo Da Riva Muñoz. [ES]
• Introducción a XMPP - Capítulo 3 - Grupos by Jacobo Da Riva Muñoz. [ES]
• Mensajería segura y abierta mediante CONVERSATIONS Xmpp on alt43.es. [ES]
• Recuperando a soberania e a privacidade da sua comunicação pessoal e corporativa by Isadora Ribeiro. [PT_BR]
• Mitigating MITMs in XMPP by Amolith for the JMP Blog.
• Setting up Slidge Gateway with Openfire for use with Whatsapp, Matrix and Telegram by surfbum for the Ignite Realtime Community.
• Per-application passwords in Tigase from the Tigase Posts.
• Join the XMPP-IT Community: Your Help Matters! The XMPP-IT community is launching a call for active collaboration — no need to be an expert, and it’s not paid work, just shared participation. From translations to testing software, writing wiki content or contributing code, there’s room for everyone. [IT]

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.17.10-2 for Android.
• Converse.js has released version 11.0.1 of its open-source and web-based XMPP chat client. The desktop version can be downloaded from here. Make sure to check out the release link for all the details!
• Gajim has released version 2.3.0 (2.3.1 and 2.3.2) with a fresh new look featuring Adwaita, adding new features, improvements, quite a few changes and bug fixes. Head over to their news section for more information. And don’t forget to read the changelog for all the details!

Gajim’s 2.3.0 sleek fresh new look featuring Adwaita

• Libervia has received NLnet funding to ‘Implement serverless (with RELOAD) and reduce metadata exposure’ (Serverless and Metadata Reduction for XMPP). This project will reduce metadata exposure and enable decentralized, serverless communication. Work will focus on end-to-end encryption specs for roster (contact list) information. These changes will be implemented in the Libervia ecosystem through Tor integration, which will help anonymize connections and reduce IP tracking. A second focus area is advancing serverless communication by implementing the RELOAD protocol XEP-0415 and leveraging end-to-end authentication via XEP-0416 and XEP-0417. This project will strengthen XMPP and Libervia’s privacy and availability, enabling their use in environments where servers may be unavailable or inaccessible.
• Monocles has released versions 2.0.8, 2.0.9, 2.0.10 and 2.0.11 of its chat client for Android, featuring many new functions and fixes.
• Prose has released versions 0.10.2 and 0.11.0 of its web frontend prose-web-app.

XMPP Servers

• The Ignite Realtime community is thrilled to announce the release of the latest versions of their popular open-source XMPP server. Openfire 5.0.0 just came out, immediately followed by Openfire 5.0.1 which should be its drop-in replacement. The new releases come packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. You can download Openfire 5.0.1 straight from the website and read the documentation to get started. Don’t forget to check out the changelog for a list of all the changes that have been made!
• MongooseIM has released version 6.4.0 of its Enterprise Instant Messaging Solution. This release brings new features, changes, various fixes and improvements. For more information, make sure to check out the changelog and the documentation.

XMPP Libraries & Tools

• go-xmpp versions 0.2.15 and 0.2.16 have been released.
• peertube-plugin-livechat versions 13.0.0 and 14.0.0 have been released.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. 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).

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.

• Data Policy
  • This document specifies metadata on how an entity handles its data (encryption, data retention, etc).
• Data Forms File Input Element
  • This specification defines an element which can be used with data forms to let users upload one or more files.

New

• No New XEPs 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.1.4 of XEP-0284 (Shared XML Editing)
  • Fix the registrar section.
  • Format the glossary better.
  • Add missing <state/> wrappers in examples.
  • Write an XML Schema. (egp)
• Version 0.9.0 of XEP-0384 (OMEMO Encryption)
  • Device labels must be signed
  • Allow empty device list in XML schema
  • Reworded security consideration that could be interpreted as forbidding trust mechanisms like BTBV/TOFU
  • Added section about dealing with lack of presence subscription
  • Removed reference to omemo-session-healing (th)
• Version 1.0.3 of XEP-0388 (Extensible SASL Profile)
  • Add missing minOccurs=‘0’ to additional-data in <continue/> in XML schema. (lnj)
• Version 0.1.1 of XEP-0485 (PubSub Server Information)
  • Fixed references to XEP identifier. (gdk)
• Version 0.1.1 of XEP-0498 (Pubsub File Sharing)
  • Fix wrong shortname and add tags. (jp)

Last Call

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

• No Last Call this month.

Stable

• No XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• Movim
• Bluesky
• LinkedIn
• YouTube
• Lemmy instance (unofficial)
• Reddit (unofficial)
• XMPP Facebook page (unofficial)

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.

Newsletter Contributors & Translations

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

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• German: xmpp.org
  • Translators: Millesimus
• Italian: notes.nicfab.eu
  • Translators: nicola
• Portuguese: xmpp.org
  • Translators: Paulo
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. 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
• communication via media accounts

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 you can support:

• Mellium Co-op
• Bifrost bridge
• Prav
• diasp.in

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

In January 2007, Ignite Realtime released the red5 plugin for Openfire which added the flash based open source Red5 media server as a plugin to Openfire (Wildfire). A year later, we added red5Phone, the first open source SIP based soft phone in a web browser.

Eighteen years later, WebRTC is now well established as the leading standard for audio and video conferencing and all that leading edge pioneer work here at Ignite evolved into Pàdé the web client, it’s supporting Openfire plugin and other plugins and clients supporting other audio and video use cases beyond meetings.

XMPP is now back in fashion and Openfire has always been a choice XMPP solution because it has the X factor. It is eXperienced, eXtensible, fleXible, eXperimental and eXciting and allowing use to easily integrate it with a wider diversity of signalling and media protocols and services.

However, the new attraction for XMPP is the push for open standards and messaging interoperability. Consequently, being able to also provide media (audio and video) interoperability in XMPP through Openfire will become one of the things we choose to focus on at Ignite going forward with audio and video communications. As previously hinted, we are moving forward with simplified, easy to maintain open standards that make media interoperability possible.

For now, that will be Online Meetings for audio and video conferencing services that have a web front end UI like Jitsi, Galene and BroadcastBox. For deeper integration into XMPP, that will be the Media Streams which is the XMPP wrapper to WHIP and WHEP.

In practice, it means development will stop on the Pade plugin for Openfire and all Jitsi based development and integration will only continue with Openfire Meetings plugin (ofmeet) which will become XEP 483 compliant. The Galene plugin for Openfire will also become XEP 483 compliant and both plugins can serve the new Online Meetings plugin for in ConverseJS web client.

The Openfire plugin called Ohun for audio conferencing is deprecated and a new plugin called OrinAyo which supports both music streaming and audio conferencing is in development and will become available very soon.

For other release announcements and news follow us on Mastodon or X

2 posts - 2 participants

Read full topic

Openfire 5.0.1 has been released!

Openfire, created by the Ignite Realtime community is a powerful chat server that lets you communicate in real-time with your team or friends. It’s like having your own private messaging solution, but with more control and customization options.

Following the release of Openfire 5.0.0 last week, a few annoying issues were reported. These are addressed in this new release:

• The Windows Launcher works again
• The bundled ‘search’ plugin is updated to address an issue in the admin console
• Certificate-based authentication can be used again with client connections
• Improvements were applied to the detection of invalid (‘ghost’) group chat users that originate from federated domains.
• The Admin Console translations for the French and Dutch languages got a significant update. Many thanks to the community members that provided those translations!

This update should be a drop-in replacement for version 5.0.0. You can find the installers in the usual places, like our Downloads page!

The 5.0.1 release of Openfire is a direct result of receiving contributions and feedback from the community. Keep it coming! As you can see, your effort, no matter how big or small, can have a direct result! Please join our community forum or group chat and let us know what you think!

Finally: GitHub appears to claim that this is our 100th release of Openfire/Wildfire. We’re not at all sure that’s an accurate count, but we’ll take the opportunity to celebrate anyway! Come join the celebrations in our chatroom! The fiftieth person to join wins a no-expenses-paid day trip to the nearest park bench!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

Slidge is an XMPP gateway designed to connect your account to third-party chat networks like WhatsApp, Telegram, or Matrix. It acts as a bridge, allowing you to send and receive messages with all your contacts directly from your single, preferred XMPP client.

This guide provides instructions to configure an Openfire XMPP server to work with Slidge and the Slidge WhatsApp plugin as an example.

Openfire requires configuration in its Admin Console to allow external components like Slidge to connect and to grant them the necessary permissions for features like file transfers.

Prerequisites

Before you begin, ensure you have:

• A running and accessible Openfire server.
• Administrative access to the Openfire Admin Console.
• Root or sudo access to the Debian/Ubuntu server where you will install Slidge.
• The Slidge Debian repository added to your system, as per the official Slidge installation instructions (Installation - Slidge documentation).

This guide used the below install method.

• (https://codeberg.org/slidge/debian)

Step 1: Configure Openfire Services

You must configure Openfire to accept the bridge connection and handle file transfers before you configure Slidge.

1.1. Install and Configure HTTP File Upload Plugin

Slidge requires a working XEP-0363 HTTP File Upload component to send and receive images, videos, and other files.

• Log in to your Openfire Admin Console.
• Navigate to Server → Plugins → Available Plugins.
• Find the plugin named “HTTP File Upload” and click the green + icon to install it.
• After installation, navigate to Server → Server Settings → HTTP File Upload.
• Ensure the box for “Enable HTTP File Upload” is checked.

Take note of the configuration. For a standard setup behind a reverse proxy, your public URL might be https://upload.your.domain while the internal service address is httpfileupload.your.domain.
We will use this internal address later.

• Click Save Settings.

1.2. Enable External Component Connections

This step allows Openfire to listen for incoming connections from bridges.

In the Openfire Admin Console, navigate to Server → Server Settings → External Components.

• Ensure the service is Enabled.
• Under the “Allowed to Connect” section, define your new WhatsApp bridge:
• Subdomain: whatsapp (This will create the JID whatsapp.your.domain).
• Shared Secret: Create a new, strong, random password.
• Copy this shared secret to a safe place. You will need it for the Slidge configuration.
• Click “Add”.

Your Openfire server is now ready for Slidge.

Step 2: Install and Configure Slidge

Now, on your server’s command line, we will install and configure the Slidge packages.

2.1. Install Slidge Packages

As per these instructions: slidge/debian: Debian (unofficial) package bundling slidge-based gateways. - Codeberg.org

2.2. Configure common.conf

This file contains settings shared by all your bridges.

• Edit the file: nano /etc/slidge/conf.d/common.conf
• Set the following parameters:

  admins=admin@your.domain
  upload-service=httpfileupload.your.domain
  user-jid-validator=.*@your.domain
  server=localhost
  #port=5347 #(default slidge setting)
  port=5275 #(openfire default)
  

2.3. Configure whatsapp.conf

This file contains the settings for the WhatsApp bridge specifically.

• Create or edit the file: nano /etc/slidge/whatsapp.conf
  (I just did mv /etc/slidge/whatsapp.conf.example /etc/slidge/whatsapp.conf)
• Add the connection details to match what you configured in Openfire:

  # The XMPP address of your bridge component
  jid = whatsapp.your.domain
  # The shared secret you created in the Openfire admin console
  secret = PASTE_YOUR_SHARED_SECRET_HERE
  legacy-module=slidge.plugins.whatsapp
  

Step 3: Start and Verify Slidge

Enable and start the Slidge WhatsApp service:

sudo systemctl enable --now slidge@whatsapp

Check the logs to ensure it started without errors:

sudo journalctl -u slidge@whatsapp -f

Step 4: User Registration and Login

From your XMPP client (e.g., Conversations, Gajim), discover the services on your server. You should see the “WhatsApp” bridge listed.

Register with the service.

The bridge (whatsapp.your.domain) will be added to your contacts. Send it the message login or qr.

(I just started a conversation with a new chat to whatsapp.you.domain and typed help, it gives a list of commands, follow these e.g register)

You may see warnings in the Slidge log about “IQ privileges not granted” for pubsub and bookmarks (XEP-0356).

Troubleshooting: Fixing Permission Warnings (not yet implemented in Openfire so can’t fix this just yet)

For good luck I also did this at the end.

sudo systemctl restart openfire
sudo systemctl restart slidge@whatsapp

1 post - 1 participant

Read full topic

Say hello to Márton Veres, our new Business Unit Leader for London.
From international consulting to leading delivery teams, Márton’s journey to this role has been anything but ordinary. In our latest team interview, he shares what excites him most about this next chapter, his vision for growing our presence in London, and a personal challenge he’s set for the summer.

Get to know Márton and his take on leadership, community, and what’s ahead.

Congratulations on your new role as Business Unit Leader (BuL) for London. Could you share more about your new role at Erlang Solutions?

Thanks! I’m proud to take on the BuL role after four years in project and delivery management here. I’ll be leading the London team, shaping and executing our business strategy, and driving growth through client relationships and new opportunities.

 I’m looking forward to working more closely with our UK colleagues, connecting with the Erlang and Elixir communities, and strengthening our presence in the London market.

What have been some highlights of your career so far?

My journey has always been at the intersection of business and technology. I spent my first eight years as an IT consultant in FinTech and Telco, helping align business needs with tech solutions. Then, I led project management teams at Deutsche Telekom for eight years, gaining deep experience in large-scale delivery. 

At Erlang Solutions, I’ve worked alongside brilliant engineers on cutting-edge Erlang and Elixir projects. The mix of consulting, corporate, and agile tech environments has given me a well-rounded perspective that I bring into this new role.

What are you most looking forward to in your new position?

I’m especially excited to deepen our work in London’s FinTech, Digital Health, and Energy sectors. I’m passionate about supporting and growing our team using servant leadership and business coaching skills I’ve developed, including through a recent certification programme supported by Erlang Solutions. 

Digital Health is a particular interest of mine, and I’d love to expand on the work we’ve done with the NHS, HCA Healthcare, and Baxter. Being part of the Trifork Group also opens up opportunities to collaborate on end-to-end solutions, especially with their Digital Health expertise.

Outside of work, what are you most excited about this summer in London?

I’m training for the Wimbledon Half Marathon in September. My goal is to finish in under two hours! It’s a great way to stay focused and make the most of the summer. Balancing work and personal goals like this keeps me energised.

Final thoughts

It’s been a pleasure catching up with Márton and hearing about his journey, leadership vision, and what’s ahead for the London team. His story is a great reminder of the passion and purpose that drive our work at Erlang Solutions.

We’ll be sharing more team stories soon. So keep an eye out for the people behind the projects. If you’d like to connect with Márton or anyone on our team, we’d love to hear from you.

The post Meet the Team: Márton Veres appeared first on Erlang Solutions.

We are thrilled to announce the release of Openfire 5.0.0, the latest version of our popular open-source XMPP (Extensible Messaging and Presence Protocol) server. This release marks a significant milestone in our journey to provide a robust, scalable, and secure platform for real-time communication.

Openfire 5.0.0 comes packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. Here are some of the key highlights:

1. Enhanced Security: We’ve made significant improvements to Openfire’s security infrastructure. These include the restoration and improvement of Certificate Revocation support, implementation of XEP-0421 for anonymous unique occupant identifiers in MUCs and updating Jetty’s embedded webserver for enhanced stability.
2. Improved Performance: Openfire 5.0.0 is designed to handle larger loads more efficiently. We’ve optimized the server’s performance to ensure it can scale to meet the needs of your growing user base. Performance improvements include updating our network interaction layer with a recent version of Netty, optimizing database queries, and reducing duplicate code in multi-providers, resulting in a more efficient and responsive system.
3. Plugin Updates: We’ve updated several of our core plugins to ensure they’re compatible with Openfire 5.0.0. This includes updates to our monitoring, clustering, and web-based chat client plugins.
4. Bug Fixes and Improvements: We’ve squashed numerous bugs and added various features in this release, improving the overall functionality, stability and reliability of Openfire. Translations have been updated (and now include Turkish, Swedish and Italian), new group chat management features have been added, and parallelism when working with many federated domains has been improved, to name a few.
5. Updated Java Requirement: Openfire requires Java 17 (or newer) to be installed.

Our deepest thanks go to NLnet Foundation for their invaluable support. With their funding and encouragement, we successfully implemented full IPv6 support and completed a robust security audit by Radically Open Security. NLNet’s mission to strengthen open and trustworthy internet infrastructure continues to make a real difference!

The changelog lists all of the changes that have been made.

We’re incredibly excited about this release and we can’t wait to see what you’ll build with Openfire 5.0.0. Whether you’re a developer looking to build a new real-time application, or an organization looking to improve your communication infrastructure, Openfire 5.0.0 has something for you.

As always, Openfire is free and open-source, so you can download it, use it, and modify it to suit your needs. We believe in the power of open-source software to drive innovation and we’re committed to continuing to support and develop Openfire.

Thank you to everyone who has contributed to this release, whether by submitting code, reporting bugs, or providing feedback. Your contributions are invaluable and we couldn’t do this without you.

You can download Openfire 5.0.0 from our website and check out our documentation to get started. We’ve also updated our community forums where you can ask questions, share ideas, and connect with other Openfire users.

Here’s to the future of real-time communication with Openfire 5.0.0!

For other release announcements and news follow us on Mastodon or X

28 posts - 12 participants

Read full topic

It is exciting to be able to announce the immediate availability of the beta release of Openfire 5.0.0!

In this release, we have addressed approximately 125 issues! I’ll reserve the details for a blog post on the 5.0.0 (non-beta) release, but some of the important changes are:

• We’ve dropped support for Java 11. The minimum requirement is Java 17 now
• The embedded web server has received a major upgrade
• Various security-related updates were applied, including library updates and code changes that resulted from an independent security audit (more on that later!)

This beta release (and some of its precursors) have been extensively tested by the developers and other members of the Ignite Realtime community. At this stage, we’re not seeing any critical issues. However, prior to cutting the full release, we prefer to have more feedback. That is where you come in!

We are looking for your help!

Please help us test this release! If you host your own instance of Openfire, please consider upgrading it to the new beta release. If you can’t, or if you’re not running Openfire but another brand of XMPP server, please do some interoperability testing with the server at igniterealtime.org.

Are you a client developer? Please see how your application behaves, when connecting to the beta (we can make available accounts for testing to help you do this).

If you’re nothing of a tech-head but can use an XMPP client, try to interact with our domain (for example, join our chatroom at open_chat@conference.igniterealtime.org) to see if there are any issues.

You can obtain the beta from our download page for beta releases or from the GitHub Releases page.

We would love to hear from you! If you have any questions, please stop by our community forum or our live groupchat. We are always looking for volunteers interested in helping out with Openfire development!

For other release announcements and news follow us on Mastodon or X

11 posts - 7 participants

Read full topic

XMPP Newsletter Banner

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

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, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XMPP Events

• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming).
• The XMPP Sprint in Berlin took place during the 23rd-25th of May 2025. Developers from Germany, France & the United Kingdom representing Conversations, Dino, ejabberd, Kaidan, LiveDashboard, Macaw, Monal, Renga, and Prose gathered to make it happen! The sprint was sponsored by the XSF, Ammonit Measurement GmbH, and Wikimedia e.V..

A still from the XMPP Sprint in Berlin, May 2025

Videos

• Goffi, from Libervia, published a short progress overview of the new web frontend design on the Libervia video channel.

Talks

• On Friday, May 16, Vril hosted the Workshop di XMPP e Free Software all’AntiBiennale di Venezia (a workshop on XMPP and free software) at Cabasego, in Venice, Italy. The whole workshop lasted around one and a half hours and the slides are freely available for you to check out. The event took place in a most beautiful house, incredibly located in the center of Venice, inhabited by people who are always willing to leave their door open to Venice’s underground communities. [IT]

XMPP Articles

• El gran lío de la mensajería instantánea by Jacobo Da Riva Muñoz. [ES]
• Monocles, the project responsible for the XMPP Monocles chat Web and Android clients, started a crowdfunding campaign. The main goal is to create a platform where privacy, digital sovereignty and sustainability take center stage. Your privacy is non-negotiable. The funding period will span from March 28 to June 30.
• XMPP is now featured on the list of the ‘Delightful Lists’.
• Towards a Password-Mukt XMPP for some thoughts and fantasies by Badri (Hippo) on how passwordless XMPP login could be achieved, either via an out-of-band mechanism or by authorizing from an already logged-in client.
• XMPP packages coming with Debian 13 as the freeze toward next stable Debian (13 or Trixie) has been engaged, an overview of the XMPP clients, servers and librairies coming with it is provided in this article from the Debian XMPP Team.

XMPP Software News

XMPP Clients and Applications

• Converse.js has released version 11.0.0 of its open-source and web-based XMPP chat client. The Desktop version can be downloaded from here. This release comes packed full of bugfixes, changes and new features. Way too many to list in here. Make sure to check out the release link for all the details!

Converse 11

• Gajim has released version 2.2.0. This release brings three new features: message retraction (via XEP-0424: Message Retraction), blocking participants in group chats, and updated support for modern group chat avatars (via XEP-0486: MUC Avatars), among many other improvements and bugfixes. Head over to their news section or check the changelog for all the details.
• Monal has released version 6.4.11 for iOS an macOS.
• Monocles Chat 2.0.7 for Android, has been released. This version brings fixes for lagging, pinned status message, I2P and more.
• Prose has released versions 0.10.1 of its web frontend prose-web-app.

XMPP Servers

• Prosody IM is pleased to announce version 13.0.2. This update addresses various issues that have been noticed since the previous release, as well as a few improvements, including some important fixes for invites. Some log messages and prosodyctl commands have been improved as well. Read all the details on the release changelog. As always, detailed download and install instructions are available on the download page for your convenience.

XMPP Libraries & Tools

• Pade plugin version 1.8.4 for Openfire has been released.
• peertube-plugin-livechat version 12.0.4 has been released.
• python-nbxmpp version 6.2.0 has been released.
• strophejs version 3.1.1 has been released.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. 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).

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.

• No XEPs proposed this month.

New

• No New XEPs 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

• No XEPs updated this month.

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 XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• Movim
• Bluesky
• LinkedIn
• YouTube
• Lemmy instance (unofficial)
• Reddit (unofficial)
• XMPP Facebook page (unofficial)

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.

Newsletter Contributors & Translations

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

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• Italian: notes.nicfab.eu
  • Translators: nicola
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi
• German: xmpp.org
  • Translators: Millesimus

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. 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
• communication via media accounts

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 you can support:

• Mellium Co-op
• Bifrost bridge
• Prav
• diasp.in

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

When you’re moving quickly in a startup, taking shortcuts in your tech stack is tempting. A quick workaround here, a temporary fix there, with plans to tidy it all up later. But later can easily turn into never.

Those early decisions, however small they seem, have a habit of sticking around. Over time, they slow you down, create technical debt, and make it harder to scale. 

This blog looks at how to avoid common startup tech mistakes by making smarter choices early on. You don’t need to build the perfect system from day one, but you do need to build something you won’t regret.

The risks of rushing your tech stack decisions

Your tech stack is the foundation of your product. Making quick choices to just keep things often comes with hidden costs.

Common examples of early tech shortcuts

• Choosing tools based on ease rather than long-term fit
• Using third-party services without proper integration planning
  
• Avoiding proper system design to save time
  
• Stacking too many frameworks or libraries to plug gaps quickly
  
• Skipping documentation, testing, or version control in the name of speed
  

What could go wrong?

Here are some of the common risks that come with rushing tech stack choices:

The business cost of technical shortcuts

They directly impact a startup’s ability to grow. From wasted dev time to lost customer trust, the cost of early shortcuts adds up fast. That’s not the kind of overhead most startups can afford.

The long-term cost of technical debt

We touched on technical debt earlier as one of the key risks of rushing early tech decisions. Now let’s look at it more closely, because for many startups, it’s the most persistent and costly issue that comes from cutting corners.

Technical debt is the build-up of compromises made during development, from skipping tests and rushing features to patching bugs without addressing their root cause. These short-term choices eventually slow everything down, making it harder and more expensive to move forward.

Let’s break down the long-term impact:

The hidden costs of technical debt

A Stripe report found developers spend up to 42% of their week handling technical debt. CIO research suggests 20–40% of IT budgets are spent addressing it.

When it gets out of control

Technical debt can halt progress entirely. We’ve seen startups and scale-ups locked into outdated or fragmented systems, where maintaining or updating anything becomes nearly impossible.

Here are a few real-world scenarios:

• Legacy overload: Systems running well past their intended lifespan, no longer supported or secure.
  
• Integration failure: Poorly connected tools and services that don’t talk to each other, slowing everything down.
  
• Scaling bottlenecks: Infrastructure so rigid that every new feature or user pushes it closer to breaking point.
  

Security crises: Outdated code with known vulnerabilities, eventually forcing a full rebuild after a breach.

What startups can do about it:

You can’t avoid technical debt entirely, but you can manage it by:

• Prioritising clean, maintainable code from day one
  
• Setting time aside for refactoring and testing
  
• Regularly reviewing architecture decisions
  
• Choosing tools that support long-term scalability, not just quick wins
  

Startups that manage technical debt proactively stay more adaptable, secure, and focused on building the future.

Why scalability matters from day one

Tech built in a rush might work for an MVP (minimum viable product), but without scalability and maintainability in mind, it becomes a liability, something we cover in more detail in our post on common MVP mistakes.

60% of startups face major scalability issues within their first three years (McKinsey). These problems aren’t just technical; they slow growth, frustrate users, and drain time and resources.

Here’s why it’s critical to get it right from the start:

1. Scaling later is harder and more expensive

Retrofitting scalability into an existing product or tech is rarely clean. The cost (in both time and money) often outweighs what it would’ve taken to plan it earlier.

2. Maintainable code accelerates growth

Clean, modular code helps teams ship faster, fix bugs quicker, and onboard new engineers smoothly. Poor code slows everything down.

3. Users don’t tolerate failure

Unscalable systems break under pressure, which is exactly when users start showing up. That erodes trust, kills momentum, and makes customer retention harder.

4. Bad tech choices can limit your future

Tech that isn’t built to adapt can lock you into tools, vendors, or architectures that no longer serve your goals. That makes pivots and product evolution harder.

Early-stage teams often defer these decisions to “later.” But in startups, later usually means too late. Thoughtful, scalable, and maintainable tech choices aren’t a luxury but a growth strategy.

Doing it Right from the start: In practice

Now that we understand why scalable and maintainable tech decisions are crucial early on, here are some practical strategies to help your startup avoid quick fixes and build a strong foundation.

1. Prioritise Root Cause

 Don’t just patch, find and fix the real problem. For example, optimise slow database queries instead of repeatedly fixing slow responses.

2. Adopt Agile

Work in short cycles and use user feedback. Many fintech startups rely on agile to adapt quickly.

3. Write Clean, Modular Code

Keep code simple and flexible. Use modular design to evolve without costly rewrites.

4. Test Early

Use automated tests early to catch bugs. Improve stability by prioritising testing from the start.

5. Review Regularly

 Hold frequent code and architecture reviews. Startups BoardClic and Metaito used expert code and architecture reviews to ensure scalable, robust platforms.

6. Choose the Right Tech

Pick tools that fit your goals and skills. Many startups use scalable, developer-friendly stacks like Elixir.

7. Document Clearly

Keep documentation up to date to help teams understand decisions and onboard new members fast.

8. Don’t skip security checks

It’s easier to fix security issues early than patch things up later. Audits, such as SAFE (Security Audit for Erlang and Elixir), helped startups like Koll and Twine ensure the security of their systems early on, making it easier to scale with confidence and avoid nasty surprises. 

Starting with these habits cuts costly fixes later and sets your startup up for lasting growth.

Balancing speed and quality without overengineering

Startups must deliver quickly but avoid building overly complex solutions too soon. The key is focusing on essential features that address real user needs, while keeping the system flexible enough to adapt later. This helps avoid wasted effort on premature optimisation or unnecessary features.

For more on this, check out our post: Common MVP mistakes: How to build smart without overbuilding.

Build now, avoid startup tech mistakes later

Startups move fast, but speed shouldn’t come at the cost of sustainability. Those early quick fixes and temporary solutions often end up sticking around. Over time, they slow you down, create technical debt, and make it harder to grow.

You don’t need to build the perfect system from day one. But you do need a foundation that won’t hold you back.

Make smart, thoughtful tech choices early. Keep things simple. Review regularly. Focus on value that lasts. That’s how you stay fast without sacrificing your future.
If you’re ready to avoid common startup tech mistakes and build something that lasts, Erlang Solutions can help, so let’s talk.

The post Avoiding Common Startup Tech Mistakes appeared first on Erlang Solutions.

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

This update addresses various issues that have been noticed since the previous release, as well as a few improvements, including some important fixes for invites. Some log messages and prosodyctl commands have been improved as well.

A summary of changes in this release:

Fixes and improvements

• mod_storage_internal: Fix queries with only start returning extra items
• mod_invites_register: Stricter validation of registration events

Minor changes

• MUC: Ensure allow MUC PM setting has valid value (fixes #1933: PM does not work on new MUCs)
• mod_storage_sql: Delay showing SQL library error until attempted load
• mod_storage_sql: Handle failure to deploy new UNIQUE index
• mod_storage_sql: Add shell command to create tables and indices (again)
• mod_s2s: Fix log to use formatting instead of concatenation (fixes #1461: Logging issues uncovered by mod_log_json)
• modulemanager, util.pluginloader: Improve error message when load fails but some candidates were filtered
• prosodyctl check config: add recommendation to switch from admin_telnet to shell
• mod_storage_sql: Retrieve all indices to see if the new one exists
• prosodyctl check config: List modules which Prosody cannot successfully load
• net.http.files: Fix issue with caching
• util.jsonschema: Fix handling of false as schema
• mod_invites: Consider password reset a distinct type wrt invite page
• configmanager: Emit config warning when referencing non-existent value
• mod_admin_shell: Add role:list() and role:show() commands
• MUC: Fix nickname registration form error handling (#1930)
• MUC: Fix Error when join stanza sent without resource (#1934)
• MUC: Factor out identification of join stanza
• mod_invites_register: Don’t restrict username for roster invites (thanks lissine)
• mod_admin_shell: Fix matching logic in s2s:close (Thanks Menel)
• mod_authz_internal: Improve error message when invalid role specified
• mod_http_file_share: Add media-src ‘self’ to Content-Security-Policy header
• mod_admin_shell: Visual tweaks to the output of debug:cert_index()
• mod_http: Log problems parsing IP addresses in X-Forwarded-For (Thanks Boris)
• mod_http: Fix IP address normalization (Thanks Boris)
• util.prosodyctl.check: Improve reporting of DNS lookup problems

Download

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!

Debian 13 "Trixie" full freeze has started 2025-05-17, so this is a good time to take a look at some of the features, that this release will bring. Here we will focus on packages related to XMPP, a.k.a. Jabber.

XMPP is a universal communication protocol for instant messaging, push notifications, IoT, WebRTC, and social applications. It has existed since 1999, originally called "Jabber", it has a diverse and active developers community.

Clients

• Dino, a modern XMPP client has been upgraded from 0.4.2 to 0.5.0
  Dino now uses OMEMO encryption by default. It also supports XEP-0447: Stateless File Sharing for unencrypted file transfers. Users can now see preview images or other file details before downloading the file. Multiple widgets are redesigned to be compatible with mobile devices, e.g. running Mobian.
• Gajim, a GTK+-based Jabber client has been upgraded from 1.7.3 to 2.1.1
  There are many new features in Gajim, e.g. XEP-0444: Message Reactions, XEP-0461: Message Replies, XEP-0425: Moderated Message Retraction, XEP-0490: Message Displayed Synchronization, voice message recording, migration to GTK 4, and a lot of UI changes.
• go-sendxmpp, a CLI tool to send messages to contacts or MUCs: 0.5.6 → 0.14.1
  New features are support for sending XEP-0066: Out of Band Data and support for several modern authentication features (XEP-0388: Extensible SASL Profile, XEP-0386: Bind 2, XEP-0484: Fast Authentication Streamlining Tokens). New support of modern SCRAM mechanisms (SCRAM-SHA-1(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-515(-PLUS)) and SASL SCRAM Downgrade Protection (XEP-0474: SASL SCRAM Downgrade Protection) improve the security of the login process. Also a lot of bugfixes and smaller improvements found their way to the new version, for details see the changelog.
• Kaidan, a simple and user-friendly Jabber/XMPP client is upgraded from 0.8.0 to 0.12.2
  Kaidan supports end-to-end encryption via OMEMO 2, Automatic Trust Management and XMPP Providers. It has been migrated to QT 6 and many features have been added: XEP-0444: Message Reactions, XEP-0461: Message Replies, chat pinning, inline audio player, chat list filtering, local message removal, etc.
• Libervia is upgraded from 0.9.0~hg3993 to 0.9.0~hg4352
  Among other features, it now also contains a gateway to ActivityPub, e.g. to Mastodon.
• Poezio, a console based XMPP client as been updated from 0.14 to 0.15.0
  Better self-ping support. Use the system CA store by default.
• Profanity, a console based XMPP client has been upgraded from 0.13.1 to 0.15.0.
  Add support for XEP-0054: vcard-temp, Improve MAM support, show encryption for messages from history and handle alt+enter as newline char.
• Psi+, a QT based XMPP client (basic version) has been upgraded from 1.4.554 to 1.4.1456
• xmpp-dns, a CLI tool to check XMPP SRV records: 0.3.4 → 0.4.5
  It now supports showing connection targets defined by XEP-0156: Discovering Alternative XMPP Connection Methods/XEP-0487: Host Meta 2 - One Method To Rule Them All and testing of XEP-0206: XMPP Over BOSH and Websocket connections. A detailed list of changes can be found in the changelog.

Servers

• ejabberd, an extensible realtime platform (XMPP server, MQTT broker, SIP service) has been updated from Version 23.01 to 24.12
  Add support for XEP-0425: Moderated Message Retraction, XEP-0402: PEP Native Bookmarks, and XEP-0424 Message Retraction.
• Prosŏdy, a lightweight extensible XMPP server has been upgraded from 0.12.3 to 13.0.1
  Admins can disable and enable accounts as needed. A new role and permissions framework. Storage and performance improvements.

Libraries

• libomemo-c 0.5.0 to 0.5.1
• libstrophe, an XMPP library in C has been upgraded from 0.12.2 to 0.14.0
  It now supports XEP-0138: Stream Compression and adds various modern SCRAM mechanisms.
• omemo-dr, an OMEMO library used by Gajim is now in Debian, in version 1.0.1
• python-nbxmpp, a non blocking Jabber/XMPP Python 3 library, upgrade from 4.2.2 to 6.1.1
• python-oldmemo, a python-omemo backend for OMEMO 1, 1.0.3 to 1.1.0
• python-omemo, a Python 3 implementation of the OMEMO protocol, 1.0.2 to 1.2.0
• python-twomemo, a python-omemo backend for OMEMO 2, 1.0.3 to 1.1.0
• qxmpp 1.4.0 to 1.10.3
• slixmpp-omemo new 1.2.2
• slixmpp 1.8.3 to 1.10.0
• strophejs, a library for writing XMPP clients has been upgraded from 1.2.14 to 3.1.0

Gateways/Transports

• Biboumi, a gateway between XMPP and IRC, upgrades from 9.0 to 9.0+20241124.
• Debian 13 Trixie includes Slidge 0.2.12 and Matridge 0.2.3 for the first time! It is a gateway between XMPP and Matrix, with support for many chat features.

Not in Trixie

• Spectrum 2, a gateway from XMPP to various other messaging systems, did not make it into Debian 13, because it depends on Swift, which has release critical bugs and therefore cannot be part of a stable release.

Digital wallets have transformed how people pay and how businesses get paid. With more consumers choosing contactless and mobile transactions, offering these payment options is part of staying relevant.

That’s why your business needs to understand digital wallet security– how it works, where the risks lie, and what it takes to protect customer data and payment information.

In this guide, we’ll walk through how digital wallets function, the benefits they offer, and why security needs to be a central part of any payment strategy.

Why digital wallet security is important 

You likely already have some understanding of the importance of digital wallet security. But the scale of risk today makes it worth revisiting.

In 2024, scammers stole $494 million in cryptocurrency through wallet-draining attacks, according to BleepingComputer. These attacks hit over 300,000 wallet addresses, a 67% jump in stolen funds compared to the year before. The number of victims? Up just 3.7%. That means attackers are going after (and reaching) higher-value targets.

And it’s not just about crypto. IBM reports that the average cost of a data breach globally is now $4.45 million, up 15% in just three years. For any business handling payments or user data, it’s a direct, growing risk. Understanding how digital wallets work and how to secure them is quickly becoming part of the baseline for doing business responsibly.

What is a digital wallet?

A digital wallet is a software-based tool that stores payment information securely on a smartphone or similar device. It allows customers to pay online or in-store without needing to enter card details or carry cash.

For businesses, it’s a shift in how people expect to transact. Digital wallets offer speed at the till, fewer failed payments, and a smoother customer experience.

More than just payments

Digital wallets do more than handle payments. Many store loyalty cards, ID, tickets, and even crypto. Some link to bank accounts, others work with preloaded funds.

Services like Apple Pay and Google Pay are already woven into consumers’ everyday lives, helping drive adoption. According to Grandview research, the global mobile wallet market reached USD 7.42 billion in 2022, and it’s expected to grow 28.3% annually through 2030, fuelled by smartphone use, internet access and booming e-commerce.

Source: Grandview Mobile Market research

Security is built in from the start

While we’ve touched on the fact that attacks and risks exist, digital wallets are inherently designed with security as a top priority.

What makes digital wallets valuable and viable is the level of built-in protection. Strong digital wallet security is a core feature, not an add-on. Encryption, tokenisation, and biometric authentication all help reduce fraud and protect customer data. The UK market is catching on fast. According to Worldpay, digital wallets are expected to handle over £200 billion in e-commerce transactions by 2027. This shift in consumer behaviour is here to stay. So ask yourself if your payment strategy is keeping up the pace.

How do digital wallets work?

Digital wallets use a mix of mobile technology and built-in security to make payments quick and easy. Whether customers are shopping online or tapping their phone in person, there’s no need to enter card details every time.

The process starts with a secure app or platform. Once a user adds their card and verifies their identity, typically using a fingerprint, face scan or PIN, the wallet is ready to use.

For in-store payments, the customer unlocks their phone, chooses a card, and holds the device close to the payment terminal. For online purchases, they simply select the wallet at checkout and approve the payment on their device.

Key tech behind digital wallets:

• Near-field communication (NFC):
  The most common method for contactless payments. NFC allows smartphones, smartwatches and compatible cards to securely exchange payment data with terminals by holding the device a few centimetres away with no physical contact needed.
  
• Magnetic secure transmission (MST):
  MST mimics the magnetic stripe on traditional cards by emitting an encrypted signal. It’s less common than NFC but still supported by some wallets and terminals.
  
• QR codes:
  Used more often in markets where contactless readers aren’t standard, QR codes allow customers to scan and pay using a barcode displayed on-screen.

Once the payment is sent, the point-of-sale system routes the data to the payment processor. From there, it goes through the standard authorisation process with the customer’s bank.

Are digital wallets safe?

We’ve covered what digital wallets are and how they work. Now, let’s get into the bigger question: how secure are they?

The risks businesses should be aware of

We have mentioned that digital wallets are designed with strong safeguards in place, but there are still risks to be made aware of. 

These typically come from user behaviour, unsecured environments, or sophisticated cyberattacks.

Here are some of the most common risks:

How to use digital wallets safely

If your business offers or accepts digital wallet payments, security is key to safeguarding your customers and protecting your reputation. With the right steps, keeping digital payments secure can be simple.

Here are some best practices businesses and their customers should follow and encourage to make digital wallet use safer:

• Use strong, unique passwords
  Avoid easy or repeated passwords across accounts. Encourage users to choose complex combinations that aren’t reused elsewhere.
  
• Enable biometric authentication
  Fingerprint or facial recognition adds an extra layer of protection beyond passwords and PINs.
  
• Keep software updated
  Regular updates patch security holes in your device’s operating system and digital wallet apps, reducing vulnerability to attacks.
  
• Separate social media and financial apps
  Using different devices or accounts for social and financial activities can lower the risk of cross-app attacks or data leaks.
  
• Be vigilant about phishing
  Train teams to recognise suspicious emails or messages that try to steal login details. Remind customers not to click on unknown links.
  

Many digital wallets come with built-in security features, including:

• Encryption and tokenisation
  These turn sensitive payment details into unreadable codes or tokens for each transaction, making data breaches far less damaging.
  
• Two-factor authentication (2FA)
  Requiring two forms of verification before access helps ensure only authorised users can make payments.
  
• Fraud monitoring
  Some wallets automatically flag or block suspicious activity to prevent unauthorised transactions.
  

In industries such as telecomms, banking and fintech, developers often rely on secure, reliable programming languages such as Erlang and Elixir to build payment systems that can handle high volumes without compromising security. 

These technologies help ensure digital wallets remain both fast and safe for everyday business use.

To conclude

For businesses, digital wallet security is essential for protecting both customers and reputation. Digital wallets include strong built-in protections, but knowing the risks and how to address them helps keep your business and customers safe.

By focusing on security, you create a safer payment environment and earn customer trust. As digital wallets become a standard payment option, staying informed and prepared will keep your business competitive and secure. Ready to discuss strengthening your payment security? Get in touch.

The post The Importance of Digital Wallet Security appeared first on Erlang Solutions.

This release brings three new features: message retraction, blocking participants in group chats, and updated support for modern group chat avatars. Thank you for all your contributions!

What’s New

Gajim 2.2 comes with support for retracting messages via XEP-0424: Message Retraction. This allow you to retract your messages, if you’ve mistakenly sent it to the wrong recipient or group chat. Please note that your counterpart needs to support this feature as well, as a retraction can only be considered an unenforceable request.

In group chats, Gajim now allows you to block individual participants, if need arises. Blocking is available through each participant’s context menu. Block lists are private, but they can be synchronized between devices. This feature is only supported by Gajim as of now.

Finally, official support for XEP-0486: MUC Avatars has been added, which allows group chats to have individual profile pictures.

A note for Windows users: At the time of writing, there are some issues with emoji rendering on Windows. That’s why there is no release of Gajim 2.2 for Windows yet. This issue should soon be resolved and we will post an update once Gajim 2.2 is released on Windows.

More Changes

• Account sidebar now indicates connectivity issues
• Handling of retraction/moderation for corrections has been improved

And much more! Have a look at the changelog for a complete list.

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

A Minimum Viable Product (MVP) is your first real signal to the market, your team, and your investors that you’re solving the right problem in the right way. While it’s often mentioned alongside terms like Proof-of-Concept (PoC), prototype, or pilot, an MVP plays a distinct role: validating real value with real users.

Avoiding common missteps early sets the stage for faster iteration, smarter growth, and long-term success. Startups are under pressure to move quickly, but speed without focus can lead to costly mistakes. Proving value fast is essential, especially with limited resources, but moving too quickly without the right foundation can stall progress just as easily as moving too slowly.

What an MVP should be

An MVP is the leanest version of your product that still delivers real value and helps you learn whether you’re solving the right problem. 

It’s not about perfection, but validation. Will users care enough to try, pay, or share? 

Importantly, a strong MVP also signals to investors that you can efficiently test ideas, understand your market, and move fast with limited resources.

Focus on what matters, build with intent, and treat your MVP not as a throwaway prototype, but as the foundation of everything to come.

Small by design, smart by strategy

Popularised by Eric Ries in The Lean Startup, the MVP is designed to reduce wasted time, money, and effort. By building only what’s needed to test your core assumptions, you can learn quickly and adjust early, before burning through too much time, money, or energy.

A good MVP doesn’t just mean “basic”

A strong MVP isn’t just a stripped-down prototype. It’s the foundation of your product. Lightweight, but also reliable, secure, and built for change. If it can’t be used, demoed, or trusted, it’s not doing its job.

Focus on what matters, build with intent, and treat your MVP not as a throwaway prototype, but as the foundation of everything to come.

Minimise risk, maximise learning

An MVP helps you move fast and stay focused. It’s not about trial and error. It’s about proving your idea works and showing investors that you’re building something ready to grow.

Common MVP mistakes (and how to avoid them)

Building an MVP is about speed and learning. But moving fast shouldn’t mean skipping the fundamentals. Many startups fall into familiar traps: doing too much too soon, choosing the wrong tools, or cutting corners that cause problems later.

By spotting these mistakes early, you can build smarter, avoid rework, and give your product a better chance of success.

Overbuilding Before Validation

Adding too many features at the start slows you down, increases costs, and weakens your core value. A bloated MVP is harder to test, more expensive to maintain, and often confusing for users.

Why it happens:

• Unclear priorities
• Perfectionism
• Fear of missing out

How to avoid it:

Focus on solving one clear problem well. Use low-code or no-code tools to test ideas quickly without overcommitting time or budget.

Choosing the wrong tech stack

Selecting technology based on trends instead of fit creates long-term issues. The wrong stack can lead to expensive rebuilds, poor stability, development slowdowns, and scaling challenges.

Why it matters:

Your tech choices affect how fast you can iterate, how well you scale, and how easy it is to adapt later.

How to avoid it:

Choose a simple, flexible stack that fits your domain. Use tools that support rapid development and long-term growth. Involve technical partners or advisors with experience to help avoid common mistakes.

Ignoring security and code quality

When speed trumps structure, the result is often messy, unreliable code.

A growing trend, vibe coding, uses AI (especially large language models) to quickly generate code from natural language. While this accelerates initial progress, it often skips testing, documentation, and consistency, leading to hidden risks and technical debt. 

Though fast at first, vibe coding can leave fragile code that’s hard to debug, extend, or transfer, with teams diverging in approach and progress stalling over time.

Why does it happen?

• Misunderstanding MVP as “low quality” rather than “focused and efficient”
• Overreliance on AI-generated code without review or standards
• Lack of experienced engineering oversight

Risks include:

• System instability and hidden failures
• Security vulnerabilities and compliance breaches
• Technical debt and poor maintainability
• Loss of trust from investors and partners

How to avoid it:

Prioritise quality from day one:

• Review AI code for security, clarity, and maintainability
• Apply secure authentication and data encryption
• Set shared coding standards and style guides
• Require basic tests and documentation, even for MVPs
• Limit LLM use in critical paths unless thoroughly validated
• Track shortcuts and log them as technical debt to resolve later

A little rigour early on prevents major setbacks down the line.

What smart MVP development looks like

A smart MVP is fast, focused, and built for flexibility. It doesn’t aim to include everything, just enough to test your core idea with real users.

Here’s what that looks like in practice:

Built fast, not rushed

Speed should serve as validation. The best MVPs reach users quickly without creating confusion or technical debt.

Focus on:

• Delivering one clear value
• Releasing early to gather feedback
• Improving in tight, focused cycles

Easy to change, because feedback is coming

A smart MVP is flexible by design. Once feedback starts coming in, you need to be ready to adjust quickly without overhauling everything.

Make this easier with:

• Modular code
• Clear documentation
• A prioritised backlog for fast iteration

Safe and secure – even if it’s lean

Even a small MVP needs to be stable and secure. If users are testing it, they’re trusting it. 

Trust depends on:

• Data security and privacy (including GDPR compliance)
• A clear, usable interface
• Consistent, reliable performance

A strong MVP is:

• Right-sized: Solves one problem well
• Stable: Works reliably in demos and tests
• Scalable: Built on a foundation that can grow
• Trustworthy: Respects and protects user data

Smart MVP development means building fast, but building right. When you combine speed with strategy, you don’t just ship faster, you learn faster, improve faster, and grow stronger.

Build fast. Build smart. Build for growth.

A strong MVP helps you validate your idea, attract early users or investors, and gather feedback, without overbuilding or overspending. The goal is not just to launch quickly, but to launch with clarity, purpose, and scalability in mind.

Many teams fall into the same traps: bloated feature sets, the wrong technology choices, or neglecting long-term costs. These missteps waste time, burn cash, and kill momentum. The most effective MVPs are built with focus, tested against the right assumptions, and grounded in a foundation that supports growth from day one.

At Erlang Solutions, we can help your startup launch MVPs that are resilient under pressure and built for the future. If you’re ready to build something that works, let’s talk.

The post Common MVP mistakes: How to build smart without overbuilding appeared first on Erlang Solutions.

XMPP Newsletter Banner

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

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, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XSF Announcements

XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, submissions are open until May 18th, 2025, 00:00 UTC!.

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 you can support:

• Mellium Co-op
• Bifrost bridge
• Prav
• diasp.in

XMPP Events

• Berlin XMPP Meetup [DE / EN]: monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month at 6pm local time.
• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming).
• XMPP Sprint in Berlin: On Friday, 23rd, Saturday, 24th, and Sunday, 25th of May 2025.

XMPP Articles

• XMPP Foundation Urges Meta to Allow Interoperability Under EU Rules by Markus Kasanmascheff for winbuzzer.com
• Monocles, the project responsible for the XMPP Monocles chat Web and Android clients, has started a crowdfunding campaign. The main goal is to create a platform where privacy, digital sovereignty and sustainability take center stage. Your privacy is non-negotiable. The funding period will span from 03.28.2025 to 06.30.2025.
• Prav has taken its second major step towards forming a cooperative society in India. Their blog post “Finalising our bye-laws” details the process, including ways you can help out. This is an important step in Prav’s mission to implement community-driven decision making for their XMPP apps and services and give legal teeth to that structure.

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.17.10-1 for Android. This version introduces an initial implementation of Spaces (XEP-503), among other improvements, bugfixes and more!
• Conversations has released versions 2.18.0, 2.18.1 and 2.18.2 for Android. Notable changes include the ability to pick a custom backup location, a prominent backup restore option for Quicksy, and improved support for more kinds of URIs. The latter includes tel phone numbers, mailto email addresses, and more interestingly the web+ap scheme for ActivityPub proposed by Fedi Links.
• Dino has released version 0.5 featuring OMEMO encryption by default, improved file transfers, image preview and other file details before downloading, and two completely reworked dialogs. See the release blog post for all the details.
  • At the same time, Dino has also received funding from NLnet to begin development on a slew of new features. This includes message moderation in group chats, local message deletion, modern connection handling with FAST and SASL2, more formatting options with Message Markup, and more! Visit the project page for all the details.
• Gajim has released versions 2.1.0 and 2.1.1 with a new ‘Activity feed’ page, layout improvements for its ‘Start Chat’ dialog and support for ‘Message Display Synchronisation’ (XEP-0490) across group chats among other improvements and bugfixes. Head over to their News section for all the details.

Activity feed in Gajim 2.1

Account and status selection in Gajim 2.1

• Kaidan has received NLnet funding for various improvement across the board, most notably multi-user chat and support for legacy OMEMO. The second point is significant because while Kaidan is using a newer version of the OMEMO end-to-end encryption protocol, other popular clients including Conversations, Monal, and Dino are still using an older version. Since the two are not compatible, this meant Kaidan users were unable to use OMEMO encryption with users of most other clients. By implementing the older spec as well, Kaidan will help bridge that gap.

• Monocles Chat 2.0.6 has been released for Android. This version brings initial support for file captions, the option to pin an unencrypted message to the top of a conversation, providers list support, and the option to register on your own XMPP server, among many other new features and improvements.

Monocles Chat 2.0.6: Initial captions to files and pin message to the top

Monocles Chat 2.0.6: Register on your own XMPP server or pick one from the providers list

• Movim has released version 0.30 (code named “Encke”), the biggest Movim evolution in many years! This release brings multi-participant calls, reactions being displayed in the detailed message view, support for Unicode 15.1 with plenty of new emojis to use, and avatars that change when a contact adds to their Story.

Movim 0.30 (Encke): Multi Participant Calls. Bob Cat looking disgruntled by the presence of the ‘Hooman’ on the lower right of the screen!

Movim 0.30 (Encke): Meow OwO bedazzled by the looks of Multi Participant Calls on his mobile device!

• and following right on its heels, Movim also published its first bug-fix release: version 0.30.1, adding animated pictures support in the image proxy and a new Avatar and Banner Configuration Panel, as well as implementing (XEP-0392) Consistent Color Generation, among many other improvements and bugfixes. Make sure to check out the official announcements at the Movim Blog for all the details!

Movim 0.30.1: Avatar and banner configuration panel

• Prose has released versions 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.9.0, 0.9.1 and 0.10.0 of its web frontend prose-web-app.

XMPP Servers

• MongooseIM has released version 6.3.3 of its Enterprise Instant Messaging Solution. This minor update includes various fixes and improvements. For more information, check out the documentation.
• ProcessOne has published ejabberd 25.04. This release brings an important security fix, several bug fixes and a new API command.
• Prosody IM is pleased to announce version 13.0.1, a new minor release from the latest stable branch. It fixes some important bugs that were discovered after the latest release. Read all the details on the release changelog. As always, detailed download and install instructions are available on the download page for your convenience.
• The Prosody app for YunoHost has been updated to provide a bunch of supported XEPs by default, configured for all YunoHost users in just one click. YunoHost is a set of tools to easily manage your own selfhosted services, and while it used to come bundled with the Prosody fork Metronome by default, it has recently bundled its XMPP functionality into a separate “app” so that people can swap in any other XMPP server of their choice.

XMPP Libraries & Tools

• go-xmpp versions 0.2.13 and 0.2.14 has been released.
• libomemo-c version 0.5.1 has been released.
• prose-core-client versions 0.1.103, 0.1.104 and 0.1.105 have been released.
• python-nbxmpp versions 6.1.0 and 6.1.1 have been released.
• Slidge versions 0.2.9 (codenamed “Trixie <3”), 0.2.10, 0.2.11 and 0.2.12 have been released.
• Tinder version 2.1.0 has been released.
• Whack version 3.0.0 has been released.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. 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).

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.

• No XEPs proposed this month.

New

• No New XEPs 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 1.1.3 of XEP-0313 (Message Archive Management)
  • Fixed typo (XEP Editor (dg))
• Version 0.4.0 of XEP-0377 (Spam Reporting)
  • Add spam report processing opt-in.
  • Add Guus der Kinderen as co-author. (gdk)
• Version 1.0.1 of XEP-0421 (Occupant identifiers for semi-anonymous MUCs)
  • Fixed typo (XEP Editor (dg))
• Version 0.3.0 of XEP-0455 (Service Outage Status)
  • Remove all in-band event signaling. (mp)

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 XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• LinkedIn
• YouTube
• Lemmy instance (unofficial)
• Reddit (unofficial)
• XMPP Facebook page (unofficial)

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.

Newsletter Contributors & Translations

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

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• Italian: notes.nicfab.eu
  • Translators: nicola
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi
• German: xmpp.org
  • Translators: Millesimus
• Português (BR): xmpp.org
  • Translators: Paulo

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. 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
• communication via media accounts

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

ElixirConf EU 2025 is only two weeks away! Soon, it will once again be time for the Elixir community from Europe and beyond to come together, connect, and learn from each other about Elixir and its ecosystem. There will be dozens of talks from speakers across the community, training opportunities, and more.

This year’s event is being held in Kraków, Poland from May 15-16, with optional training available on May 14. Both in-person and virtual tickets are available.

Here’s a preview of some of the speakers on the schedule, and what to expect from their talks:

Keynotes

José Valim: Type System and Elixir Updates

No ElixirConf would be complete without an appearance from Dashbit’s José Valim, the creator of Elixir.

Since announcing it at ElixirConf EU 2022, José and the Elixir team have been hard at work on a type system for the language based on set-theoretic types. Implementation of this system is still underway, and José will offer an update on its progress, as well as other recent activities from the Elixir team and what to expect in the next release. Guillaume Duboc, a PhD student at Université Paris Cité who is working on the type system for his thesis, will provide a more in-depth look at it in a separate talk, “What’s New with Elixir Types”.

James Arthur: Introducing Phoenix.Sync

James Arthur is a TED Prize and Microsoft Prize-winning co-founder of Opendesk, Hazy, and Post Urban, with prior software development experience for Apple and IDEO.

He is currently the CEO of ElectricSQL, developers of the Elixir sync engine Electric, and will be bringing that knowledge to his keynote introducing Phoenix.Sync, a new library that adds real-time sync to Phoenix. Expect a tour through the basics of the library, how to use it to sync data into both backend and frontend applications, and its potential uses in AI systems.

Davide Bettio and Mateusz Front: The AtomVM and New Horizons for Elixir

SECO Mind’s Davide Bettio has years of embedded systems and IoT experience, and began work on AtomVM, a lightweight BEAM implementation tailored for IoT devices, in 2017.

He’ll be joined by Mateusz Front, an Elixir developer at Software Mansion, to explain the results of a collaboration that has proved Elixir can be run on a whole new platform. They’re keeping quiet about the specifics, so you’ll have to check out their keynote to find out what they’ve come up with, along with plenty more information about AtomVM and Elixir runtimes.

Industry Stories

Anita Ludermann: Turn Old Into New: Moving to Elixir Feature by Feature

Anita Ludermann is a software engineer currently at Modell Aachen GmbH, where she has spent the last few years working with a team whose goal is to modernise a legacy codebase by transitioning it to Elixir.

She’ll be offering a first-hand account of what adoption of Elixir and the functional paradigm in general looks like in a real-world industry context, with all the challenges of shifting an entire system to a new language bit by bit while maintaining consistent functionality for the user.

Ettore Berardi: How Elixir Powers the BBC: From PoC to Production at Scale

After a stint at MacMillan Science and Education, Ettore Berardi joined the BBC, where he has now been working for eight years as a tech lead.

He’ll be relaying another story of Elixir adoption in action, namely the four-year process of shifting to Elixir at the BBC, starting with an initial proof of concept and culminating with nearly all BBC app and web traffic being served by Elixir. On top of the technical side of things, he’ll also discuss the realities of building and maintaining Elixir expertise in an environment largely unfamiliar with the language.

Libraries and Frameworks

Gus Workman: Introducing Trellis: Open Source Hardware for Nerves

You may already be familiar with Nerves, a framework for using Elixir to build embedded systems. Gus Workman is the founder of Protolux Electronics, a company specialising in Nerves-based hardware and software.

His talk will introduce Trellis, an open-source hardware platform reminiscent of Raspberry Pi, but specifically built with the purpose of producing custom circuit boards for Nerves and Elixir.

Parker and Shannon Selbert: The Architecture of Oban Web

Oban Web, the live dashboard for the prominent Elixir background job library Oban, recently became fully open source.

Now, Oban’s creator Parker Selbert and Oban core team member Shannon Selbert, co-founders of Soren, will be diving into the internals of the project, touring its key elements and interesting features. They promise to reveal how to structure a complex LiveView application with extensive real-world use, backed by Oban Met, a purpose-built distributed database.

Ridwan Otun and Sola-Aremu ‘Pelumi: Whisperer: An Elixir-Based Multi-Agent Framework

Ridwan Otun and Sola-Aremu ‘Pelumi are two self-described Elixir evangelists working as engineering vice presidents at Juicyway and Bank of America, respectively.
Their talk will introduce Whisperer, a new and recently open-sourced framework that allows users to define, sequence, and orchestrate multi-agent AI systems. It’s another talk that’s well worth checking out if you’re interested in learning how Elixir developers are taking advantage of the new possibilities afforded by agents and LLMs.

Deep Dives

Conor Sinclair: Meta-Programming in Elixir: Dynamic Function Calling with LLMs

Multiverse’s Conor Sinclair is a senior software engineer specialising in frontend and with a passion for Elixir.

 He’ll be joining the conference to address the now-ubiquitous topic of LLMs. Conor will be addressing Elixir specifically, walking the audience through the process of creating generic interfaces and using the Langchain library to expose them to LLMs. It’s sure to be a fascinating talk for anyone curious as to how these models interface with an existing application.

Robert Virding: Unveiling the Magic of Erlang/OTP Behaviours: A Deep Dive in the Codebase & Björn Gustavsson: My Beam History

We’ll also be getting talks from two developers whose experience with Erlang and the BEAM goes back to the very beginning. Robert Virding was one of the co-creators of Erlang at Ericsson, and now works for Erlang Solutions as Principle Language Expert.
He’ll be offering a deep dive into the Erlang/OTP codebase, as well as a BEAM VM training session the day before the conference proper. Björn Gustavsson, meanwhile, joined the OTP team in 1996 and later became the main developer for the BEAM, which is partially named for him. His talk will explore his three decades of history with the BEAM.

And More!

Of course, that’s only a fraction of the talks at this year’s event – there are plenty of others, and it’s worth checking out the full list of speakers to see if there’s anything else that catches your eye. If you’ve already committed to attending, the schedule is now available, so you can start deciding which talks to attend.

There’s sure to be something for everyone with an interest in Elixir and the BEAM, and Erlang Solutions will be present at the event as always, so be sure to say hi to our team if you do attend. We hope to see you in Kraków in a few weeks for ElixirConf EU 2025!

The post Looking Forward to ElixirConf EU 2025 appeared first on Erlang Solutions.

“When an operation cannot be expressed by any of the functions in the Enum module, developers will most likely resort to reduce/3.”

From the docs for Enum.reduce/3

In many Elixir applications, I find Enum.reduce is used frequently. Enum.reduce can do anything, but that doesn’t mean it should. In many cases, other Enum functions are more readable, practically as fast, and easier to refactor.

I would also like to discuss situations that are a good fit for Enum.reduce and also introduce you to a custom credo check I’ve created, which can help you identify places where Enum.reduce could be replaced with a simpler option.

Readability

Here are a few common reduce patterns—and their simpler alternatives.  For example, here’s something I see quite often:

Enum.reduce(numbers, [], fn i, result -> [i * 10 | result] end)
|> Enum.reverse()

This is a situation that the Enum.map function was designed for:

Enum.map(numbers, & &1 * 10)

Perhaps you know about Enum.map, but you might see a call to reduce like this:

Enum.reduce(numbers, 0, fn number, result -> (number * 2) + result end)

Let me introduce you to Enum.sum_by!

Enum.sum_by(numbers, & &1 * 2)

Let’s look at something a bit more complex:

Enum.reduce(numbers, [], fn item, acc ->
  if rem(item, 2) == 0 do
    [item * 2 | acc]
  else
    acc
  end
end)
|> Enum.reverse()

This is a perfect case for piping together two Enum functions:

numbers
|> Enum.filter(& rem(&1, 2) == 0)
|> Enum.map(& &1 * 2)

Another option for this case could even be to use Enum.flat_map:

Enum.flat_map(numbers, fn number ->
  if rem(number, 2) == 0 do
    [number * 2]
  else
    []
  end
end)

This is a decent option, but while this achieves the purpose of both filtering and mapping in a single pass, it may not be as intuitive for everybody.

Lastly, say you see something like this and think that it would be difficult to improve:

Enum.reduce(invoices, {[], []}, fn invoice, result ->
  Enum.reduce(invoice.items, result, fn item, {no_tax, with_tax} ->
    if Invoices.Items.taxable?(item) do
      tax = tax_for_value(item.amount, item.product_type)
      item = Map.put(item, :tax, tax)

      if Decimal.equal?(tax, 0) do
        {no_tax ++ [item], with_tax}
      else
        {no_tax, with_tax ++ [item]}
      end
    else
      {no_tax, with_tax}
    end
  end)
end)

But this is just the same:

invoices
|> Enum.flat_map(& &1.items)
|> Enum.filter(&Invoices.Items.taxable?/1)
|> Enum.map(& Map.put(&1, :tax, tax_for_value(&1.amount, &1.product_type)))
|> Enum.split_with(& Decimal.equal?(&1.tax, 0))

Aside from improving readability, splitting code out into pipes like this can make it easier to see the different parts of your logic.  Especially once you’ve created more than a few lines of pipes, it becomes easier to see how I can pull out different pieces when refactoring.  In the above, for example, you might decide to create a calculate_item_taxes function which takes a list of items and performs the logic of the Enum.map line.

Performance

You may have already thought of a counterpoint: when you pipe functions together, you end up creating new lists, which means more work to be done as well as more memory usage (which means more garbage collection).  This is absolutely true, and you should be thinking about this!  

But I find that 99% of the time, the data I’m working with makes the performance difference negligible.  If you find that your code is slow because of the amount of data that you need to process, you might try using the Stream module — it has many of the same functions as Enum, but works lazily.  If that doesn’t work, then by all means, create a reduce (and maybe put it into a well-named function)! 

 As Joe Armstrong said:

“Make it work, then make it beautiful, then if you really, really have to, make it fast.”

For some information about benchmarks that I’ve run to understand this better, see this analysis and discussion.

Good Opportunities for Enum.reduce

Aside from occasional performance reasons, Enum.reduce can often be the simplest solution when you want to transform a data structure over a series of steps.  For example:

• Build a data structure based on an enumerable (like a fragment in an Ecto query)
• Transform a data structure (like replacing variable references in a string)

Find Cases in Your Own Code with credo_unnecessary_reduce

Remember that no one pattern works in all cases, so know what tools you have available! If you’d like to quickly find instances for potential improvements in readability, I built a Credo check to help spot where reduce can be swapped for something simpler.

You can drop it into your project and start catching these anti-patterns automatically.

https://github.com/cheerfulstoic/credo_unnecessary_reduce

Simply add it to your mix.exs file:

{:credo_unnecessary_reduce, "~> 0.1.0"}

…and then enable it in your .credo.exs file:

{CredounnecessaryReduce.Check, []}

The post Reduce, Reuse… Refactor: Clearer Elixir with the Enum Module appeared first on Erlang Solutions.

The tech world doesn’t slow down, and neither do we. From the power of big data in healthcare to keeping you up-to-date about fintech compliance, our latest blog posts explore the important topics shaping today’s digital world.

Whether you’re leading a business, building software, or just curious about the future of tech, check out what the Erlang Solutions team has been talking about.

Understanding Big Data in Healthcare

From smartwatches to digital patient records, healthcare is generating more data than ever before. In our post, Understanding Big Data in Healthcare, we explore how big data is transforming patient care—think predictive health trends, precision medicine, and smarter decision-making.

We also dig into the challenges of handling sensitive information and how tech like Erlang, Elixir, and SAFE can help keep that data secure. It’s a must-read if you’re curious about how data is shaping the future of healthcare.

Understanding Digital Wallets

Digital wallets aren’t just convenient, but they’re quickly becoming essential. In Understanding Digital Wallets, we break down how they work, why they’re gaining momentum, and what they mean for businesses today.

From improved security and cost savings to global access and smoother customer experiences, this blog gives a clear look at the benefits (and a few of the challenges) of going digital.

Women in BEAM

Lorena Mireles takes us through the key takeaways from her Women in BEAM survey, while also sharing her personal journey within the Elixir community.

From representation gaps to the importance of strong role models, this piece highlights real experiences from developers in the BEAM ecosystem and why inclusion still matters in tech.

Top 5 IoT Business Security Basics 

Billions of connected devices = billions of entry points for hackers. In Top 5 IoT Business Security Basics, we outline five practical tips to boost your IoT security:

• Use strong, unique passwords
• Encrypt your data
• Run regular security audits
• Train your team
• Disable features you don’t use

Simple, effective, and easy to implement—these tips will help you keep your systems (and customers) safe.

DORA Compliance: What Fintech Businesses Need to Know

As of January 2025, the Digital Operational Resilience Act (DORA) is live, and if you’re in fintech, you need to be ready. Our post, DORA Compliance: What Fintech Businesses Need to Know, breaks down what DORA is, who it affects, and what steps you need to take to stay compliant (if you haven’t already).

We explore its five key pillars and how to build a more resilient, disruption-proof business. With over 22,000 companies affected, it’s a timely read for anyone in the financial space.

To conclude

Staying ahead in tech doesn’t have to be overwhelming. Our goal? To make it easier for you to understand what’s happening and what it means for your business.

Got questions? Let’s chat.

The post Erlang Solutions’ Blog round-up appeared first on Erlang Solutions.

This release brings layout improvements to Gajim’s Start Chat dialog, an improved message search, and includes fixes for some issues with Message Displayed Synchronization. Thank you for all your contributions!

What’s New

Gajim 2.1 comes with a new ‘Activity feed’ which displays events around group chat invitations, contact requests, and updates. This will be the central feed for all kinds of activities in the future (e.g. reactions, replies, mentions, message reminders).

Activity feed in Gajim 2.1

Gajim 2.1.1 brings layout improvements for its Start Chat dialog, which now renders more compact and shows more information. This release also improves message search by displaying the last correction of a message and by not showing moderated messages. Last but not least, some issues with XEP-0490: Message Displayed Synchronization have been fixed.

A note for Windows users: At the time of writing, there are some issues with emoji rendering on Windows. That’s why there is no release of Gajim 2.1 for Windows yet. This issue should soon be resolved and we will post an update once Gajim 2.1 is released on Windows.

More Changes

• Group chats now show voice request errors, if they happen
• Setting your status for multiple accounts though the account sidebar now works properly

And much more! Have a look at the changelog for a complete list.

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

Just a few weeks after previous release, ejabberd 25.04 is published with an important security fix, several bug fixes and a new API command.

Release Highlights:

• Fix handling multiple occupant-id
• Kick_users API command

If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

Other contents:

• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 25.04 download & feedback

Below is a detailed breakdown of the improvements and enhancements:

mod_muc_occupantid: Fix handling multiple occupant-id

Fixed issue with handling of user provided occupant-id in messages and presences sent to muc room. Server was replacing just first instance of occupant-id with its own version, leaving other ones untouched. That would mean that depending on order in which clients send occupant-id, they could see value provided by sender, and that could be used to spoof as different sender.

New kick_users API command

There is a new API command kick_users that disconnects all the client sessions in a given virtual host.

Acknowledgments

We would like to thank the contributions to the source code, documentation, and translation provided for this release by:

• Travis Burtrum for reporting problem in occupant-id
• Marcos de Vera Piquero for the new kick_users API command
• Besnik Bleta, updated the Albanian translation
• Sketch6580, updated the Chinese translation
• Nautilusx, updated the German translation
• Silvério Santos, updated the Portuguese translation
• Wellington Uemura, updated the Portuguese (Brazil) translation
• Максим Горпиніч, updated the Ukrainian translation

And also to all the people contributing in the ejabberd chatroom, issue tracker...

Improvements in ejabberd Business Edition

For customers of the ejabberd Business Edition, in addition to all those improvements and bugfixes:

• Bugfix on max_concurrent_connections for mod_gcm, mod_webhook and mod_webpush

ChangeLog

This is a more complete list of changes in this ejabberd release:

Security fixes

• mod_muc_occupantid: Fix handling multiple occupant-id

Commands API

• kick_users: New command to kick all logged users for a given host

Bugfixes

• Fix issue with sql schema auto upgrade when using sqlite database
• Fix problem with container update, that could ignore previous data stored in mnesia database
• Revert limit of allowed characters in shared roster group names, that will again allow using symbols like :
• Binary installers and ejabberd container image: Updated to Erlang/OTP 27.3.2

Full Changelog

https://github.com/processone/ejabberd/compare/25.03...25.04

ejabberd 25.04 download & feedback

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

The source package and installers are available in ejabberd Downloads page. To check the *.asc signature files, see How to verify ProcessOne downloads integrity.

For convenience, there are alternative download locations like the ejabberd DEB/RPM Packages Repository and the GitHub Release / Tags.

The ecs container image is available in docker.io/ejabberd/ecs and ghcr.io/processone/ecs. The alternative ejabberd container image is available in ghcr.io/processone/ejabberd.

If you consider that you&aposve found a bug, please search or fill a bug report on GitHub Issues.

With ejabberd 25.03, the Matrix gateway (mod_matrix_gw) now supports not only one-to-one chats, but also joining Matrix rooms via XMPP. That’s right — your favorite XMPP client can now talk to Matrix users or hop into Matrix rooms just like regular MUCs. ✨

In this guide, we’ll show a quick demo of:

1. One-to-one chat between an XMPP and a Matrix user.
2. Joining a Matrix room and chatting from your XMPP client.

And the best part? You don’t need to install a Matrix client at all. Keep your favorite XMPP client near, welcome to the magic of federation & interoperability.

🛠 Setup Summary

We won’t repeat the full configuration steps here — they’re already covered in this earlier blogpost and the 25.03 release note.

In short, you’ll need:

• A properly configured ejabberd server with mod_matrix_gw
• Block outgoing connections to lethe.matrix.org to avoid conflicts with their XMPP instance

Here’s a minimal config snippet:

listen:
  -
    port: 8448
    module: ejabberd_http
    tls: true
    request_handlers:
      "/_matrix": mod_matrix_gw

modules:
  mod_matrix_gw:
    key_name: "xxxxxx"
    key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    matrix_id_as_jid: true

Wondering what is the Matrix signing key? Please refer to previous blog post: Matrix gateway setup with ejabberd

Still not sure if your setup is correct? Try Matrix Federation Tester to check if everything is wired up properly.

🧪 One-to-One Chat (XMPP ↔ Matrix)

In your XMPP client (e.g. Psi), add a Matrix contact using this format:
matrixUser%theirMatrixServer.tld@yourXMPPserver.tld

In my case, that means:
adrien-p1%matrix.org@matrix.mickael.m.in-app.io

On the Matrix side (e.g. Element Web), your contact will get a request. Once accepted, you’re good to chat!

🧪 Join a Matrix Room from your XMPP Client

Alright, let’s join a public Matrix room now.

From your XMPP client, you can join any Matrix public room using this format:
#matrixRoom%theirMatrixServer.tld@yourXMPPserver.tld

We’ll use the following room: #ejabberd-demo:matrix.org, so in my case, that means joining:
#ejabberd-demo%matrix.org@matrix.mickael.m.in-app.io

Once connected, you’ll be able to send and receive messages from any other participant, just like in a regular MUC. :)

🐞 Known Caveats

There&aposs still a lot of work to do to make it seamless, here&aposs a short list of currently known caveats:

• Room presence can be overwhelming in large rooms (thousands of Matrix users may appear "online").
• No E2EE support between Matrix and XMPP — encryption must be disabled for now.
• If the server restarts, 1-to-1 conversations must be restarted (re-added), as persistence is not implemented yet.
• Only Matrix room protocol versions 9, 10, and 11 are supported.

🧵 Wrapping Up

With this, ejabberd makes another step into being a powerful bridge into the Matrix federation, for both private and public communication.

It’s a great way to keep using your favorite XMPP tools while staying connected to Matrix communities.

Got feedback? Drop us a line in the comments or open a PR.

Happy bridging! 🙌

Dino is a secure and open-source messaging application. It uses the XMPP (Jabber) protocol for decentralized communication. We aim to provide an intuitive and enjoyable user interface.

The 0.5 release improves the user experience around file transfers and includes two completely reworked dialogs.

Improved file sharing

The way file transfers are currently done in the XMPP ecosystem is limited in functionality and files can sometimes be received out-of-order. Dino now supports a new method for announcing file transfers (XEP-0447), which solves this issue. Additionally, users can now see preview images or other file details before downloading the file. Dino currently only uses the new method for unencrypted file transfers, for example in public channels. Encrypted file transfers will also support the new protocol once Dino supports full-stanza encryption. All file transfers now also display the upload or download progress.

Reworked dialogs

The account and preferences dialogs have been combined into a single, new dialog. This dialog lets you manage accounts and adjust encryption and other settings. It now also includes some new settings like an option for OMEMO encryption by default, which is enabled by default.

Additionally, the conversation details dialog has been completely redesigned. Both dialogs are now fully compatible with mobile devices.

Colors and more

Dino now uses the same fallback avatar colors as other clients (XEP-0392), creating a more consistent experience across applications.

A new unread line has been added, indicating the point up to which you’ve already read the messages.

Dino has also switched from CMake to Meson, which allows for an easier development process.

Alentejo

We named this Dino release “Alentejo” after a region in Portugal.

Alentejo is a region in southern Portugal that is known for its wide plains that are dotted with wineyards and cork trees. The region has a Mediterranean climate with summers regularly reaching temperatures above 40 degrees.

Currently, about 3.6% of all deaths in the region are caused by heat. Heatwaves, in particular, pose a serious health risk and are expected to become more frequent and severe due to global warming [1]. If CO₂ emissions keep increasing, heat-related deaths could make up 15.8% of all deaths in the region by 2100. However, if action is taken to combat climate change, this number could be limited to 6.6% [2].

The IgniteRealtime community is happy to announce releases for two of its projects! Both are for XMPP-libraries that we produce.

Tinder is a Java based XMPP library, providing an implementation for XMPP stanzas and components. Tinder’s origins lie in code that’s shared between our Openfire and Whack implementations. The implementation that’s provided in Tinder hasn’t been written again from scratch. Instead, code has been moved from the original projects into Tinder, preserving al of the existing features and functionality.

The v2.1.0 release of Tinder is a maintenance release. It updates various libraries that are used by Tinder, and removes deprecated, unused code. Tinder now requires Java 11 or later. The full list of changes in this release can be found in the release notes.

Whack is a Java library that easily allows the creation of external components that follow the XEP-0114: Jabber Component Protocol. This library allows you to create server-sided components of your XMPP network that can run as stand-alone processes. That’s particularly useful when you are creating functionality for which scalability configuration differs from that of Openfire, or if you want to re-use your component for XMPP servers other than Openfire!

The v3.0.0 release of Whack is a maintenance release. It improves reconnection logic (when connection to the XMPP server is lost), it no longer ships with an embedded webserver (that was old, unused, and was raising vulnerability warnings, and updates some libraries (such as Tinder) to more recent versions. The fulll list of chagnes in this release can be found in the release notes.

We would love to hear from you! If you have any questions, please stop by our community forum or our live groupchat.

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic