The inaugural Code BEAM Lite London conference was held at CodeNode last month, featuring 10 talks, 80 attendees, and an Erlang Solutions booth. There, attendees had the chance to set a high score in a BEAM-based asteroid game created by ESL’s Hernán Rivas Acosta, and win an Atari replica.

Learning from and networking with experts across the BEAM world was an exciting opportunity. Here are the highlights from the talks at the event.

Keynote: Gleam’s First Year

Louis Pilfold kicked things off with an opening keynote all about Gleam, the statically-typed BEAM language he designed and developed, and which announced its version 1.0 a year ago at FOSDEM in Brussels. 

Louis laid out the primary goals of v1: productivity and sustainability, avoiding breaking changes and language bloat, and extensive, helpful, and easily navigable documentation. He then walked us through some of the progress made on Gleam in its first year of official release, with a particular focus on the many convenience and quality-of-life features of the language server, written in Rust. Finally, he measured Gleam’s success throughout 2024 in terms of Github usage and sponsorship money and looked forward to his goals for the language in 2025.

The Art of Writing Beautiful Code

“Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 per cent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!” Most of us are likely familiar with this famous Joe Armstrong quote, but what does it actually mean to write beautiful code? 

This question was the focus of Brujo Benavides’ talk, a tour through various examples of “ugly” code in Erlang, some of which may well be considered beautiful by programmers trying to avoid repeating code. If beauty is in the eye of the beholder, what’s more important is that each project has a consistent definition of what “beautiful” means. Brujo explored different methods of achieving this consistency, and how to balance it with the need for fast commits of important changes in a project.

Why Livebook is My Dream Data Science Workbench

Amplified’s Christopher Grainger took a more cerebral approach to his talk on Livebook, drawing on his background as both a historian and a data scientist to link the collaborative notebook software to a tradition of scientific collaboration dating back thousands of years. 

In his view, the fragmentation of the digital age led to key components of this tradition being lost; he explored how LiveBook’s BEAM architecture brings it closer to being a digital equivalent of real-time collaboration in a lab than prior technologies like Jupyter Notebooks, and what further steps could be taken to get even closer to it in the future.

Deploying Elixir on Azure With Some Bonus Side Quests

Matteo Gheri of Pocketworks provided an industrial example of Elixir in action, explaining how his company used Azure in the course of building a Phoenix app for UK-based taxi company Veezu. 

Azure is used to host only 3.2% of Elixir apps, and Matteo walked through their journey figuring it out in detail, touching on deployment, infrastructure, CI/CD, and the challenges they encountered.

Let’s Talk About Tests

Erlang Solutions’ own Natalia Chechina took the stage next for a dive into the question of tests. She explored ways of convincing managers of the importance of testing, which types of test to prioritise depending on the circumstances of the project, and how to best structure testing in order to prevent developers from burning out, stressing the importance of both making testing a key component of the development cycle and cultivating a positive attitude towards testing.

Eat Your Greens: A Philosophy for Language Design

Replacing Guillaume Duboc’s cancelled talk on Elixir types was Peter Saxton, developer of a new language called Eat Your Greens (EYG). The philosophy behind the title refers to doing things that may be boring or unenjoyable but which lead to benefits in the long run, such as eating vegetables; Peter cited types as an example of this, and as such EYG is statically, structurally, and soundly typed. He then walked through other main features of his language, such as closure serialisation as JSON, hot code reloading, and the ability for it to be run entirely through keyboard shortcuts.

Trade-Offs Using JSON in Elixir 1.18: Wrappers vs. Erlang Libraries

Michał Muskała has a long history working with JSON on the BEAM, starting with his development of the Jason parser and generator, first released in 2017. He talked us through that history; writing Jason, turning his focus to Erlang/OTP and proposing a JSON module there, and then building on that for the Elixir JSON module, now part of the standard library in 1.18. 

He discussed the features of this new module, why it was better to use wrappers while transitioning to Elixir instead of calling Erlang directly, and how to simplify migration from Jason to JSON in advance of OTP 27 eventually being required by Elixir.

Distributed AtomVM: Let’s Create Clusters of Microcontrollers

A useless machine and a tiny, battery-free LED device played central roles in Paul Guyot’s dive into AtomVM, an Erlang- and Elixir-based virtual machine for microcontrollers. He kicked off by demonstrating La machine, the first commercial AtomVM product, albeit without an internet connection, before explaining AtomVM’s intended use in IoT devices, and the recent addition of distributed Erlang. This was backed up by another demonstration, this time of the appropriately named “2.5g of Erlang” device. Finally, he explained AtomVM’s advantages compared to other IoT VMs and identified the next steps for the project.

Erlang and RabbitMQ: The Erlang AMQP Client in Action

Katleho Kanyane from Erlang Solutions then provided another industry use case, discussing how he helped to implement a RabbitMQ publisher using the Erlang AMQP client library while working with a large fintech client. Katleho talked through some of the basics of RabbitMQ implementation, best practices, and two issues he ran into involving flow control, an overload prevention feature in RabbitMQ that throttles components and leads to drastically reduced transfer rates. He wrapped up by discussing lessons he learned from the process and laying out a few guidelines for designing a publisher.

Keynote: Introducing Tau5 – A New BEAM-Powered Live Coding Platform

The closing keynote was also the only talk of the day to kick off with a music video, though that should be expected when live coding artist and Sonic Pi creator Sam Aaron is the one delivering it. Sam spoke passionately about his goal to make programming something that everyone should be able to try without needing or wanting to become a professional and discussed his history of using Sonic Pi’s live coding software in education, including how he worked some complicated concepts such as concurrency in without confusing students or teachers.

He then discussed the limitations of Sonic Pi and how they are addressed by his new project, Tau5. While still in the proof-of-concept stage, Tau5 improves on Sonic Pi by being built on OTP from the ground up, being able to run in the browser, and including new features like visuals to add to live performances. He concluded with a demonstration of Tau5 and an explanation of his intentions for the project.

Final Thoughts

Code BEAM Lite London 2025 was a fantastic day filled with fascinating talks, cool demos, and plenty more to excite any BEAM enthusiast.

From hearing about the latest Gleam developments to diving into live coding with Tau5, it was clear that the community is thriving and full of creative energy. Whether it was learning tips for practical BEAM use or exploring cutting-edge new tools and languages, there was something for everyone.

If you missed out this time, don’t worry: you’ll be welcome at the next one, and we hope to see you there. Until then, keep building, keep experimenting, and above all keep having fun with the BEAM!

The post Highlights from Code BEAM Lite London 2025 appeared first on Erlang Solutions.

Kaidan supports Qt 6 now! In addition, this release improves the user interface and fixes some bugs. Have a look at the changelog for more details.

Changelog

Features:

• Highlight public XMPP provider titles while card is expanded (melvo)
• Round corners of cards and buttons (melvo)
• Add fading in/out hover effect to map previews (melvo)
• Collapse contact profiles by default if they have more than 3 entries (melvo)
• Show colored check mark for delivered messages instead of none to avoid message bubble resizing (melvo)

Bugfixes:

• Fix opening public MUC-based group chats via another XMPP client (melvo)
• Fix playing voice messages and changing playing position (melvo)
• Fix updating message reactions that could not be sent instead of adding them a second time (melvo)
• Fix updating group chat users in user interface (melvo)
• Fix displaying message reaction details (melvo)
• Update filtering contacts by labels even if label list is not open anymore (melvo)
• Fix scrolling media overview (melvo)
• Fix updating draft messages (melvo)

Notes:

• Kaidan requires Qt 6.6 now (mlaurent, melvo, fazevedo, plata)

Download

• Source code (.tar.xz) (sig signed with 04EFAD0F7A4D9724)
• Linux (Flatpak on Flathub)

Or install Kaidan for your distribution:

The Digital Operational Resilience Act (DORA) is now in effect as of 17th January 2025, making compliance mandatory for fintech companies, financial institutions, and ICT providers across the UK and EU. With over 22,000 businesses impacted, DORA sets clear expectations for how firms must manage operational resilience and protect against cyber threats.

As cybercriminals become more sophisticated, regulatory action has followed. DORA is designed to ensure that businesses have the right security measures in place to handle disruptions, prevent data breaches, and stay operational under pressure.

Yet, despite having time to prepare, 43% of organisations admit they won’t be fully compliant for at least another three months. But non-compliance isn’t just a delay. It comes with serious risks, including penalties and reputational damage.

So, what does DORA mean for your fintech business? Why is compliance so important, and how can you make sure you meet the requirements?

What is DORA?

With technology at the heart of financial services, the risks associated with cyber threats and ICT disruptions have never been higher. The European Parliament introduced the Digital Operational Resilience Act (DORA) to strengthen the financial sector’s ability to withstand and recover from these digital risks.

Originally drafted in September 2020 and ratified in 2022, DORA officially came into force in January 2025. It establishes strict requirements for managing ICT risks, ensuring financial institutions follow clear protection, detection, containment, recovery, and repair guidelines. 

A New Approach to Cybersecurity

This regulation marks a major step forward in cybersecurity, prioritising operational resilience to keep businesses running even in the face of severe cyber threats or major ICT failures. Compliance will be monitored through a unified supervisory approach, with the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA) working alongside national regulators to enforce the new standards.

A report from the European Supervisory Authorities (EBA, EIOPA, and ESMA) highlighted that in 2024, of the registers analysed during a ‘dry run’ exercise involving nearly 1,000 financial entities across the EU, just 6.5% passed all data quality checks. This shows just how demanding the requirements are, and the importance of getting it right early for a smooth path to compliance.

The Five Pillars of DORA

DORA introduces firm rules on ICT risk management, incident reporting, resilience testing, and oversight of third-party providers. Rather than a one-size-fits-all approach, compliance depends on factors like company size, risk tolerance, and the type of ICT systems used. However, at its core, DORA is built around five key pillars that form the foundation of a strong operational resilience framework.

Source: Zapoj

These pillars also serve as the basis for a DORA compliance checklist, which businesses can use to ensure they meet regulatory requirements.

Below is a breakdown of each pillar and what businesses need to do to comply:

1. ICT Risk Management

Businesses must establish a framework to identify, assess, and mitigate ICT risks. This includes:

• Conducting regular risk assessments to spot vulnerabilities.
• Implementing security controls to address identified risks.
• Developing a clear incident response plan to handle disruptions effectively.

2. ICT-Related Incident Reporting

Companies must have structured processes to detect, report, and investigate ICT-related incidents. This involves:

• Setting up clear reporting channels for ICT issues.
• Classifying incidents by severity to determine response urgency.
• Notifying relevant authorities promptly when serious incidents occur.

3. Digital Operational Resilience Testing

Financial institutions are required to test their ICT systems regularly to ensure they can withstand cyber threats and operational disruptions. This includes:

• Running simulated attack scenarios to test security defences.
• Assessing the effectiveness of existing resilience measures.
• Continuously improving systems based on test results.

4. ICT Third-Party Risk Management

DORA highlights the importance of managing risks linked to third-party ICT providers. Businesses must:

• Conduct due diligence before working with external service providers.
• Establish contractual agreements outlining security expectations.
• Continuously monitor third-party performance to ensure compliance.

5. Information Sharing

Collaboration is a key part of DORA, with financial institutions encouraged to share cyber threat intelligence. This may include:

• Participating in industry forums to stay informed about emerging threats.
• Sharing threat intelligence with peers to strengthen collective defences.
• Conducting joint cybersecurity exercises to improve incident response.

By following these five pillars, businesses can build a strong foundation for digital resilience. Compliance isn’t just about meeting regulatory requirements, it’s about safeguarding operations, protecting customers, and strengthening the financial sector against growing cyber threats.

How to Achieve DORA Compliance for Your Business

Regardless of the stage of compliance a business is in, there are a few key areas that must be focused on to protect themselves. Here’s what you need to do:

Understand DORA’s Scope and Requirements

The first step to DORA compliance is understanding what’s required. Take the time to familiarise yourself with its requirements and ask any questions.

Conduct a Risk Assessment

A solid risk assessment is at the heart of DORA compliance. Identify and evaluate risks across your ICT systems—this includes everything from cyber threats to software glitches. Understanding these risks helps you plan how to minimise their impact on your operations.

Create a Resilience Strategy

With your risk assessment in hand, develop a tailored resilience strategy. This should include:

• Preventive Measures: Set up cyber defences and redundancy systems to prevent disruptions.
• Detection Systems: Ensure you can quickly spot any anomalies or threats.
• Response and Recovery Plans: Have clear plans in place to respond and recover if an incident happens.

Invest in Cybersecurity and IT Infrastructure

To meet DORA compliance for business, invest in strong cybersecurity tools like firewalls and encryption. Ensure your IT infrastructure is resilient, with reliable backup and recovery systems to minimise disruptions.

Strengthen Incident Reporting

DORA stresses the importance of quick and accurate incident reporting. Establish clear channels for detecting and reporting ICT incidents, ensuring timely updates to authorities when needed.

Build a Culture of Resilience

Resilience is an ongoing effort. To stay compliant, create a culture where resilience is top of mind:

• Provide regular staff training.
• Regularly test and audit your systems.
• Stay updated on emerging risks and technologies.

Partner with IT Experts

DORA compliance can be tricky, especially if your team lacks in-house expertise. Partnering with IT service providers who specialise in compliance can help you meet DORA’s requirements more smoothly.

Consequences for Non-Compliance 

We’ve already established the importance of meeting DORA’s strict mandates. But failing to comply with these regulations can have serious consequences for businesses- from hefty fines to operational restrictions. Here’s what businesses need to be aware of to protect their organisation:

Fines for Non-Compliance

• Up to 2% of global turnover or €10 million, whichever is higher, for non-compliant financial institutions.
• Third-party ICT providers could face fines as high as €5 million or 1% of daily global turnover for each day of non-compliance.
• Failure to report major incidents within 4 hours can lead to further penalties.

Reputational Damage and Leadership Liability

• Public notices of breaches can cause lasting reputational damage, affecting business trust and relationships.
• Business leaders can face personal fines of up to €1 million for failing to ensure compliance.

Operational Restrictions

• Regulators can limit or suspend business activities until compliance is achieved.
• Data traffic records can be requested from telecommunications operators if there’s suspicion of a breach.

How Erlang Solutions Can Help You with DORA Compliance

Don’t panic, prioritise. If you’ve identified that your business may be at risk of non-compliance, taking action now is key. Erlang Solutions can support you in meeting DORA’s requirements through our Security Audit for Erlang and Elixir (SAFE).

With extensive experience in the financial sector, we understand the critical need for resilient, scalable systems. Our expertise with Erlang and Elixir has helped leading fintech institutions, including Klarna, Vocalink, and Ericsson, build fault-tolerant, high-performing and compliant systems.

SAFE is aligned with several key areas of DORA, including ICT risk management, resilience testing, and third-party risk management:

• Proactive Risk Identification and Mitigation: SAFE identifies vulnerabilities and provides recommendations to address risks before they become critical. This proactive approach supports DORA’s requirements for continuous ICT risk management.
• Continuous Monitoring Capabilities: SAFE allows ongoing monitoring of your systems, which aligns with DORA’s emphasis on continuous risk detection and mitigation.
• Detailed Incident Response Recommendations: SAFE’s detailed findings help you refine your incident response and recovery plans, ensuring your systems are prepared to quickly recover from cyberattacks or disruptions.

Third-Party Risk Management: The security audit can provide insights into your third-party integrations, helping to ensure they meet necessary security standards and comply with DORA’s requirements.

Conclusion

DORA compliance is now in effect, making it essential to act if your business isn’t fully compliant. Delays can lead to penalties and increased risk exposure. Prioritising ICT risk management, strengthening resilience, and ensuring proper incident reporting will bring you closer to compliance. But this isn’t just about meeting requirements, it’s about safeguarding your organisation and building long-term operational resilience.

If you have compliance concerns or just want to talk through your next steps, we’re here to help. Contact us to talk through your options.  

The post DORA Compliance: What Fintech Businesses Need to Know appeared first on Erlang Solutions.

XMPP Summit 27 - January 2025

For this year’s XMPP Summit 27, real time communication enthusiasts gathered in Brussels (Belgium, EU) to discuss a wide range of XMPP topics.

Topics included:

• GC3 (a new group chat protocol)
• HTTP Upload retention
• Service Discovery updates
• User account configuration
• Spam reporting
• OMEMO device management
• MIMI/MLS (encryption)
• IMNG
• MUC Push
• Updates from the Editor
• Talks about XMPP and the EU, about reducing pre-connection roundtrips, and about experimenting with remote control of (Galene) video conferences

A detailed report can be found at mathieui’s blog.

We’re excited to announce a new way to connect with our community at process-one.net. As of today, we’ve enabled free memberships on our site, giving you even more ways to stay updated, interact, and engage with our content.

Why Sign Up?

By becoming a member, you get access to specific benefits, including:

• The ability to engage with our content in new ways, such as commenting on posts, participating in discussions like we did before and receiving exclusive insights.
• A direct connection to the ProcessOne team and the latest updates on ejabberd, Fluux.io, technical insights and our other projects.
• Email notifications when new articles are published.

Ghost’s (our blogging platform, right here) membership is designed to help build an engaged community. It allows users to stay informed, participate actively, and create a closer connection —without any cost or commitment, while ensuring our content remains valuable to a genuine human audience. It means we are re-enabling comments here (disabled while we switched away from our Wordpress instance), which is the most important aspect of this membership.

We have no plans for paid memberships; our goal is simply to share updates about our projects and the XMPP ecosystem. Additionally, we respect your privacy—your email will only be used to notify you about new content, and we will never sell or misuse it.

It&aposs Free and easy to join.

Signing up is completely free—just create an account and start enjoying the benefits right away. No strings attached!

Prefer RSS? We’ve Got You Covered

If you prefer to follow updates through RSS, you can always subscribe to our feed and get the latest content delivered straight to your reader of choice. Subscribe over here. ;).

We’re always looking for new ways to enhance the experience for our readers, and this is just the beginning. We hope you’ll join us and be part of our growing community!

Sign up today and stay connected!

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of January 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 until February 16th, 2025, 00:00 UTC!.

XMPP Summit 27

The XSF held its 27th XMPP Summit on January 30th & 31st 2025 in Brussels (Belgium, Europe). During this two-day gathering, we discussed XMPP protocol development topics and kept making progress on current issues within the protocol and ecosystem. We would like to thank everyone that took part of the Summit for their continuous commitment and contribution to the XSF and all the XMPP related projects!

The XSF would like to extend a special thank you to those who made the Summit possible:

• Daniel Gultsch for his time and resources to help organizing the event.
• Alexander Gnauck and Dave Cridland for sponsoring the XSF Dinner.
• Ralph Meijer for his time and dedicated work on streaming/swag/booking dinner.
• Edwin Mons for the dinner form.
• Kevin Smith for leading the Summit and moderating the speakers.
• Alex Palaistras for keeping up a record on the pad with all the topics and the feedback during the entire Summit.
• Isode for sponsoring the XMPP Summit again.

Welcome to the 27th XMPP Summit!

You can find a summary of the main topics discussed over the course of the Summit here.

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 iOS
• 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).
• PravConf 2025: PravConf 2025 is the first edition of the annual gathering of the Prav community, and it will be held on March 1, 2025, at the Model Engineering College, in Kochi. Feel free to Join the group to learn more!
• XMPP Sprint in Berlin: On Friday, 23rd, Saturday, 24th, and Sunday, 25th of May 2025.

Talks

XMPP Articles

• ProcessOne
  • How Big Tech Pulled Off the Billion-User Heist.
• Erlang Solutions
  • MongooseIM Round-Up.
• Prosody Certificate Management With Nginx and Certbot by Sahil Dhiman.

XMPP Software News

XMPP Clients and Applications

• Conversations has released versions 2.17.8 and 2.17.9 for Android.
• Monal has released version 6.4.9 and 6.4.10 for iOS an macOS.
• Monocles Chat 2.0.4 has been released for Android. This version brings in several fixes.
• Cheogram has released version 2.17.2-4 for Android.
• Movim 0.29 and 0.29.1 have been released. Movim 0.29 (code named “Rankin”) is the first XMPP client that implements “Stories” (XEP-0501 (Pubsub Stories)), a very nice way to share content with your contacts and allow them to react easily by chat. It also introduces “Briefs”, a simpler way to create a short publication that only consists of a text and some medias on your profile or in your Communities. Version 0.29.1 comes with a more polished and improved “Stories” feature, database fixes as well as some preparatory work for the PHP 8.4 version. To learn more about this releases, head over to the Movim Blog.

Movim 0.29 (Rankin) introducing Stories!

Movim 0.29 (Rankin) introducing Briefs!

XMPP Servers

• MongooseIM has released version 6.3.1 of its Enterprise Instant Messaging Solution.

XMPP Libraries & Tools

• Slixmpp version 1.8.6 has been released (release announcement)
• Slidge versions v0.2.3, v0.2.3.post1 and 0.24 have been released.
• QXmpp versions 1.9.3 and 1.9.4 have been released.
• go-xmpp version 0.2.10 has been released.
• go-sendxmpp version 0.14.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.

• GRE Formatter: MIME
  • This GRE Formatter uses Multipurpose Internet Mail Extensions (MIME) to format payload.
• GRE Encrypter: OpenPGP
  • This GRE Encrypter uses OpenPGP to encrypt payload.
• Gateway Relayed Encryption
  • This specification describes a mechanism for end-to-end encryption with gateways that is compatible with third-party networks.

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.4.2 of XEP-0424 (Message Retraction)
  • Use a XEP-0425 /me command in the fallback body
  • State that a tombstone’s <retracted/> element’s ‘id’ attribute should match the retraction message’s ‘id’.
  • Specify XEP-0359 as a dependency and require that the stanza ‘id’ be used instead of the origin-id.
  • Update the “Security Considerations” to mention the risk of non-unique message IDs. (jcb)
• Version 0.4.0 of XEP-0474 (SASL SCRAM Downgrade Protection)
  • Use better value delimiter (tm)

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.

• Last Call for comments on XEP-0484 (Fast Authentication Streamlining Tokens).
  • This Last Call shall end at the close of business on 2025-01-27

Stable

• Version 1.0.0 of XEP-0421 (Occupant identifiers for semi-anonymous MUCs)
  • Accept as Stable as per Council Vote from 2025-01-14. (XEP Editor(dg))

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• Twitter
• YouTube
• LinkedIn
• 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, 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

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.

Here is an account of my trip to FOSDEM & XMPP Summit this year. Note: for privacy reasons on the broader internet, I am keeping names out of my description of the events, but my goal here is not to diminish anyone’s merit.

In this post, I will share the results of the Women in BEAM 2024 survey. But first, I would like to share my experience in the BEAM community to understand the motivation behind this initiative.

My journey

I’ve been working with Elixir since 2018, but my interest in it wasn’t driven by technical advantages—it was sparked by my experience at my first ElixirConf in Mexico.

Since 2017, I’ve been involved in initiatives supporting women in tech, frequently attending events to learn and observe industry gender gaps. A major challenge I noticed was the barrier of seniority—many talks were difficult to follow for newcomers, and women, already underrepresented (often less than 30% of attendees), could feel even more excluded. Unfortunately, I grew used to this dynamic, but it was always awkward.

In 2018, I was invited to ElixirConf Lite in Mexico City. From the start, I felt welcomed—no barriers, no judgment, just an open and friendly community. Inspired by this inclusivity, I decided to explore Elixir, later falling in love with its technical strengths.

Since then, I’ve combined my passions for diversity in tech and Elixir. A few months ago, I committed to a focused initiative: the survey.

Background

I have been part of the Code BEAM America committee during the last three editions. I know the efforts made to have a gender-balanced panel and promote diversity at the conference, such as the Diversity & Inclusion Programme. Initiatives that have undoubtedly yielded results. 

For example, the following graph corresponds to the number of women at CodeBEAM America since 2015:

There is an increase between each edition for almost all of them, and there are some, such as the one in March 2021, where the percentage is nearly a quarter. However, getting female speakers remains a challenge every year. 

I know many women working with Elixir and some with Erlang or Gleam. When I invite them to give a talk, their common response is, “Oh! I don’t think I have anything interesting to share”.I know it’s not true, but I don’t blame them because I know the feeling. Sometimes, I have stopped sharing content or talks for fear of not having enough experience, and I often get so nervous that I let the impostor syndrome win.

As I mentioned earlier, my initial reason for getting interested in Elixir was inclusion. During all these years, I have never had a bad experience in the community, which led me to wonder what is behind these barriers. The cultural context has a lot to do with it, and it is not something specific to the BEAM community; however, I was interested in learning more about other women’s perspectives on the topic.
There were a good number of responses for this first edition, and based on the open responses, I decided to focus the results on four main sections: Diversity in Roles, Challenges for Junior Developers, Programming Language Preferences, and Diversity and Inclusion.

Survey Highlights

The survey included many open-ended questions, and while all responses were different, some aspects were repeated across many, so the sections below are grouped based on similar responses.

Diversity in Roles

I decided to start with this section because role diversity is directly related to the topic of role models, which, from my perspective, is a determining factor in promoting greater participation of women in the BEAM community.

According to this article, women occupy only 11% of leadership positions in technology. This represents a barrier for women working in the industry and new generations, who may not easily see themselves reflected in these numbers. Aspiring to a leadership position is much easier when you have an example in mind, whether it’s a public figure, a teacher, a coworker, etc. This also applies to open-source contributions, technical talks, and more.

Therefore, it is essential to highlight the diversity of responses to the question about the primary role.
The majority of women surveyed indicated that they are Software Developers/Engineers. I wasn’t surprised since most women I know in the community play this role, but I was thrilled that this wasn’t the only answer, so let’s dig deeper into those who indicated they played a different role.

• One woman shared that she is dedicated to research and teaching, a direct way to pass on knowledge and experience. BEAM languages are often overlooked in education, as functional programming isn’t typically prioritised, but having a mentor can change that.

A teacher can encourage event participation, recommend key books, and even organise group attendance. Most importantly, integrating Elixir or Erlang into lessons sparks interest in new learners. Research also plays a vital role, inspiring students to explore deeply and cultivate the curiosity we value in the community.

• There is one mention of a Technical Leader and two of an Engineering Manager, both refer to leadership positions that can represent role models for those aspiring to be team leaders and manage greater responsibilities. It is important to mention that the years of experience are different for the three answers. This breaks the myth that a position is associated with years of experience rather than with the knowledge and value these women bring to a team.

• One respondent is a student, though her school level isn’t specified, so it’s unclear if she had prior BEAM experience. Still, it’s clear the BEAM community has successfully expanded its reach—not just in the workplace but also among students who can share their enthusiasm with peers and teachers.

Finally, there is a Project Manager answer, which is a big plus for someone working with a team of developers. Experience in the technical side and the technologies used in a project or team allows for a deeper understanding and better technical suggestions; she can encourage attendance at events to improve the team’s skills and promote using BEAM languages ​​in other areas.

Challenges for Junior Developers

This section is interesting as the survey had no direct questions about juniors and their challenges. Still, I decided to add it because there was an open question about how easy it was for women to get a BEAM-related job. Even those who indicated that from their perspective it was easily mentioned that it depends on the years of experience and that for juniors, it is complex because companies prefer to hire someone with previous experience rather than train someone. Let’s analyze the answers: 

Most women surveyed said they had between 3 and 5 years of experience working with a BEAM programming language.

57.1% of the total indicated that they currently have a BEAM-related job, but despite this, 71.4% consider that it is not easy to find job opportunities.

The reasons are mainly related to two factors: one is that on popular platforms such as LinkedIn, there are not as many offers as other technologies, and they do not know which other pages or media to look at. The second reason is due to the challenges that juniors face, and we will delve into that one for now.

“It is difficult to get a job because (BEAM technologies) are not broadly used, and it is harder for many people to have previous production experience.”

Many of the responses in this section agree that it is relatively easy to get a BEAM job when you already have at least two years of experience.

“If you are a junior developer, getting a job is very hard / Most companies only offer senior positions.”

I understand the problem, and in the end, it becomes a vicious circle: someone with no experience can’t get a job, but how can she get it if she can’t join a team? So, talking about external expertise beyond what a company can provide is essential.

I love working with Elixir because you can start a project from scratch and see results quickly. The documentation and resources—tutorials, blogs, and books—are excellent, and the same likely applies to languages like Gleam.

You can build experience through personal projects, coding challenges, or even creating a website. I enjoy writing to reinforce my learning, and if you do too, I encourage you to start a blog—it’s a great way to gain experience and make yourself visible.

Here are some resources to get you started:

• The Elixir programming language
• Erlang/OTP
• Gleam programming language
• Events and resources (community wiki)

Another indirect way to gain experience is by attending events. The 68.6% of women surveyed stated that they like attending virtual and in-person events, and 28.6% indicated that they only like virtual events. 

Attending meetups and conferences helps you learn about current technical challenges, BEAM updates, etc. Even if you are starting, it will give you an idea of ​​the topics you can focus on.

These actions may seem irrelevant since they are not the same as saying that you have x years of experience in a company, but they will undoubtedly make a difference. They will also help you find the area where you would like to specialize or learn more, get to know the community, and open the possibility of finding mentors.

Programming Language Preferences

I’m an Elixir developer, so I initially decided to focus the survey on just that programming language, as it’s familiar to me. However, seeing content about Erlang and Gleam in the community is becoming more common, so I decided not to limit it, and I was pleasantly surprised by the diversity of responses.

Most women indicated that Elixir is the primary programming language they use, but it was not the only one. In this question, 14.3% indicated they work with Erlang and 11.4% with Gleam.

Additionally, the survey included a question about other technologies, either as a hobby or as a secondary language. Most women working with Elixir as a primary technology indicated that they were experimenting with Erlang as an additional language and vice versa. This is not surprising, as if you work with Elixir and dig into the fundamentals, you must explore Erlang. On the other hand, if your primary programming language is Erlang, it can be pretty fun and easy to explore Elixir.

Something else worth mentioning in this question was that there was a mention of LFE and EML. I was surprised because at least I don’t know both fundamentals, but it made me think about everything I still have to explore in BEAM and the alternative options. In some way, it also motivated me to investigate more about it, and that is precisely the meaning of the community: sharing knowledge.

As an extra, someone else mentioned that although it wasn’t a programming language per se, their favorite secondary technology was LiveView.If you, like me, are curious to explore everything that BEAM has to offer, you can find out more about it in the following list: Languages, and about languages, on the BEAM.

Diversity and Inclusion

I believe diversity and inclusion are strongly promoted in the BEAM community, setting it apart from other technologies. I was eager to hear other women’s perspectives, whether they share this view, and what actions we can take to improve further.

This section explores several related questions in depth, but the key takeaway is that most agree diversity and inclusion are actively encouraged in the community.

Of the total number of women surveyed, 82.9% consider that diversity and inclusion are promoted in the BEAM community, compared to 17.1% who think they are not.

Women who think no, indicated that this is because they know few or no other women in the company who work with any BEAM programming language and they do not know of any initiatives working on this topic, however, there is no reason beyond that, they have never had any gender issues and they like to attend community events.

On the other hand, women who believe that these topics are promoted shared that the main reason is thanks to the warmth of the people. For example, at events where they felt safe to share without fear of being judged, or when you contact one of the pioneers on social media and have support and even mentoring in some cases.

“From my experience at Code BEAM Europe, the BEAM community felt very welcoming. It seemed like a space where people could make mistakes, try new things, and learn together. That openness makes it easier for different perspectives to be part of the conversation.”

So far, so good, the general outlook is positive, but there is a tricky aspect to mention: 4 women reported having had gender problems in the community. This question was a one-way question and I did not go into the subject in depth so as not to make these women uncomfortable, but it is certainly an aspect that needs to be worked on.

This gives us a lead into the next section, the steps to follow.

Actionable Steps

The actions listed here aren’t solely focused on gender issues but aim to make the BEAM community more inclusive, based on suggestions from the women surveyed.

Gender Policies and Codes of Conduct

Many respondents highlighted the need for clear gender policies and better awareness of them. They support reinforcing codes of conduct at conferences, ensuring attendees know who to contact if issues arise.

One woman admired a company’s anti-harassment policy, and I agree—though few respondents reported problems, we must not minimise the issue. Strong community support makes addressing misconduct easier.

Spaces Dedicated to Women in BEAM

This was a recurring theme. Many women cited impostor syndrome as a barrier to participation and expressed interest in safe spaces to ask questions, practise talks, and seek advice.

“In my case, I don’t feel 100% comfortable in the environment but I am not sure how to promote greater participation. Maybe it will help if we create a small subgroup for women/nonbinary in the community to promote ourselves or to share projects and ideas.”

“Create women’s support groups. Where we can have learning sessions, mentors, talk about the working environment, talk about career levels to look forward to, give advice, etc.”

Support for beginners

Going back to the topic of the challenges faced by juniors, some of the suggestions are also to promote more content for those women who have little or no experience with BEAM and especially focus on the reasons why it is worth giving it a try.

Role Models

This is definitely my favourite measure. I have always been a supporter of promoting role models in technology to encourage more girls and teenagers to become interested in this, so I was delighted to know that this is a common opinion.

Many of the women surveyed pointed out that having a role model in the community can help with the goal of getting more women interested and participating.

“Highlighting the work of women already active in the community can make a difference. Seeing other women as speakers and leaders may encourage more to step forward.”

“I think the more visible women are in the community, the more women will participate.”

“Just seeing other women speak is an example to me. Seeing others who are relatable to me helps me realize I can just get up there and be me and speak on something I am interested in.”

These are just a few of the related responses.

Acknowledgements

 I would like to take this opportunity to mention the names of the people who came up in the survey, as many of the women mentioned that they do not have a female role model, but that along the way they have met men who support diversity and would like to acknowledge that.

Laura Castro, Elaine Naomi, “Tobias Pfeiffer who really advocates for diversity”, Robert Virding, Peer Stritzinger, Sigu Magwa,  Sophie Benedetto, “Female role models are Ingela Andin from the OTP team, her history and dedication to working with the BEAM are great, and Hayleigh from the Gleam team, she is such a brilliant person”, “Some of my favourite folks I have seen speak, and who make me feel included in the community are: Meks McClure, Miki Rezentes, Jenny Bramble”, and to the women who mentioned me, thank you so much, I want to tell you that you made me smile a lot.

Women in BEAM Conclusion

I would like to thank all the women who took part in the survey, and to everyone who shared it on social media or with colleagues. Most of all, thank you to those who care about diversity and inclusion and work to make the BEAM community better every day.

I’ll be following up on all the comments and suggestions, and some women have even reached out to collaborate, which I’ll also pursue. Based on the responses, I’ve decided to make the survey an annual initiative. The details are still in the works, but I’ll keep you updated.

Lastly, thanks to all the role models in companies, schools, and the community, who inspire more women to discover how incredible Women in BEAM is.

See you in the next edition!

The post Women in BEAM appeared first on Erlang Solutions.

Businesses can’t afford sluggish, unresponsive systems, especially when dealing with high volumes of concurrent requests. Slow applications lead to lost revenue, frustrated users, and missed opportunities. This is where Elixir comes in.

Purpose-built for scalability and concurrency, Elixir runs on the battle-tested Erlang Virtual Machine (BEAM), a technology trusted to power fault-tolerant, high-availability systems. 

Keep reading to discover 5 key reasons why Elixir scalable concurrent applications can help your business handle growth efficiently and maintain high performance under demand.

A bit of background on Elixir

Elixir was created in 2012 by Ruby developer Jose Valim. The Ruby programming language has long been considered the standard for developing enterprise apps because it is well-built and has a great framework. But Ruby was built at a time when we didn’t have the same system demands as we do now. Today, applications often run into issues with concurrency and scaling up applications. 

Valim wanted to enable higher extensibility and productivity for use in building large-scale sites and apps. For this, he turned to the older Erlang programming language. Erlang was built as a telecom solution with massive concurrency and the ability to handle millions of phone call connections. Building on top of Erlang and combining all the benefits of Ruby led to the high-concurrency, low-latency language we know today.

Now that you have some background let’s get straight into the five reasons Elixir stands out for building scalable and concurrent systems.

1) Elixir Excels in Scalability and Concurrency

Built on the Erlang Virtual Machine (BEAM), Elixir efficiently handles thousands, even millions, of simultaneous processes.

The Actor Model

Elixir’s concurrency model is based on the Actor model, which provides a message-passing system between processes.

Source: Lightbend

The “Actor Model” is for doing many things at the same time. It works by using actors as the basic building blocks. Think of them as little machines that can do things independently of each other and talk to each other by sending messages. Each of these little machines is called “processes”.

This way of working makes it easy to build systems that can handle multiple things at once, even when issues occur.

2) Fault Tolerance for Reliable Applications

Elixir’s supervisor mechanism enables applications to recover from failures automatically, ensuring uninterrupted service. Elixir’s processes are isolated from each other, which means that if a process fails, it does not affect the entire system. Developers can also use Elixir’s built-in error-handling mechanisms to handle errors gracefully.

Fault tolerance systems. Source: Finematics 

3. A Robust and Growing Ecosystem

Elixir has a large ecosystem of libraries and frameworks that can help developers build scalable and concurrent applications. One of the most popular frameworks is Phoenix. It provides features such as real-time communication, web sockets, and channels, which make it an ideal choice for building scalable and concurrent web applications. 

Elixir also has libraries such as GenServer, which provides a simple and powerful way to build concurrent applications.

Other ecosystems also include Mix, a build tool that automates many tasks in creating Elixir applications. Mix provides tasks for creating new projects, testing, and deploying applications. Mix is also extensible, allowing developers to create their tasks and plugins.

4. Developer-Friendly and Supported by a Thriving Community

A major draw to Elixir also lies in its simplicity. Its clean, easy-to-learn syntax allows developers to write efficient, high-performing code with minimal effort. Even those new to functional programming can quickly become proficient, increasing productivity. 

Elixir also boasts a passionate and growing community that regularly contributes new libraries, tools, and resources to keep the language modern and powerful. This strong community support makes it easier for newcomers to learn and for businesses to find skilled Elixir developers. 

5. Proven Success with Leading Companies

Major companies like Discord, Pinterest, Bleacher Report and Moz trust Elixir to handle their high-traffic operations. These real-world use cases highlight Elixir’s ability to scale and perform under heavy demand.

You can check out our case studies page to learn more about other great businesses that are using Elixir.

Conclusion

In a world where every second counts, sluggish systems just don’t cut it.

Elixir scalable concurrent applications provide the performance and reliability businesses need to thrive, even under heavy demand. With its rock-solid fault tolerance and vibrant community, Elixir is a game-changer for companies looking to scale and stay ahead.

If you’d like to learn more about Elixir, drop the team a line.

The post 5 Reasons to Build Scalable and Concurrent Applications with Elixir appeared first on Erlang Solutions.

Digital wallets, once considered futuristic, have now become essential tools for both consumers and businesses. But what are digital wallets, and why should you care about them? Customer expectations are changing. Many companies are turning to them to streamline transactions and enhance the customer experience

This guide unpacks the fundamentals of digital wallets, highlighting their benefits, market trends, and implications for businesses.

What Are Digital Wallets?

Digital wallets (or e-wallets) have changed the way we make and receive payments. By 2025, digital payments are expected to account for 50% of global payments.

At their core, digital wallets store a user’s payment information, securely encrypted for seamless transactions. This could involve credit card details, bank accounts, or even cryptocurrencies.

Apple Pay, Google Wallet, PayPal, and Samsung Pay have become household names, but the ecosystem is much broader and growing rapidly as more industries recognise their potential. Digital wallets simplify purchases and integrate with loyalty programmes, personal finance management, and even identity verification, offering a comprehensive solution for consumers and businesses alike.

How Do Digital Wallets Work?

Digital wallets offer a secure and straightforward way to manage transactions. In a time when data breaches are increasingly common, security has never been more important. With cybercrime damages projected to reach $10.5 trillion annually in 2025, they play a major role in keeping financial information safe.

Here’s how they work. First, you link your financial details to the wallet. This could mean adding a credit card or connecting a bank account. Once your details are in, the wallet uses encryption and tokenisation to protect your sensitive information, converting it into a secure format that’s almost impossible for unauthorised parties to access.

When you make a payment, the process is quick and simple: tap, scan, or click. Behind the scenes, your digital wallet securely communicates with the payment processor to authorise the transaction. With advanced security measures like encryption and tokenisation, digital wallets not only reduce the risk of fraud but also allow for a seamless and reliable user experience.

Types of Digital Wallets

Now let’s explore the various types of digital wallets available:

1. Closed wallets

2. Semi-closed wallets

Semi-closed wallets like Paytm or Venmo, allow payments at select merchant locations or online stores that accept their platform.

3. Open wallets

Backed by major financial institutions, open wallets allow broader transactions, including withdrawals, online purchases, and transfers. Popular examples include PayPal and Google Pay.

4. Prepaid Wallets

Prepaid wallets let you load funds in advance, so you use only what’s available. Once the balance is depleted, you just reload the wallet. This approach is great for budgeting.

Choosing the right digital wallet depends on your business model. 

Whether you’re looking for customer loyalty through closed wallets or broader international reach with open wallets, selecting the right type will drive better engagement and efficiency.

Why Should Businesses Care?

The rise of digital wallets represents a strategic opportunity for businesses to serve their customers better and improve their bottom line. Here’s why:

Enhanced customer experience

Digital wallets streamline the checkout process, reducing friction and improving customer satisfaction. Features like one-click payments and loyalty integrations can drive repeat business.

Improved security

Tokenisation and encryption reduce the risks associated with traditional payment methods. This not only protects users but also helps businesses build trust.

Cost efficiency

Payment processors for digital wallets often charge lower fees than those for traditional credit card transactions, which can run as high as 3%. Depending on the provider, digital wallets can significantly cut these costs.

Global reach

For companies aiming to expand internationally, digital wallets simplify cross-border transactions by supporting multiple currencies.

Digital wallets offer tangible benefits: enhanced customer experience, improved security, and cost efficiency. Businesses that integrate them can streamline payments and improve retention and satisfaction, driving growth.

Integrating Digital Wallets into Your Business

Before jumping into digital wallets, it’s worth taking a moment to plan things out. A bit of strategy can go a long way.

Here are some key things to keep in mind:

• Know what your customers want: Look at your data or run a quick survey to find out which wallets your customers use most.
• Pick the right payment processor: Go for a provider that supports lots of wallets. This gives you flexibility and makes it easier to grow.
• Focus on security: Work with experts, like Erlang Solutions, to help build secure systems that keep data safe and meet the necessary guidelines around payments.
• Test, optimise and refine: Start with a proof of concept to see how things work. We can help you get this done quickly so you can adjust and stay ahead of the game.

By understanding what your customers need and choosing flexible payment options, you can bring digital wallets into your business without any hiccups. Picking the right tech also means your operations keep running smoothly while you embrace innovations.

Challenges and Considerations

While digital wallets offer numerous benefits, they’re not without challenges:

• Adoption barriers: Older demographics or tech-averse users may still prefer traditional payment methods. According to AARP, about 50% of older adults in the U.S. feel uncomfortable with new payment technologies. Businesses need strategies to educate and ease this transition.
  
• Risk of fraud: While secure, digital wallets are not immune to hacking or phishing attacks. Companies must ensure continuous security updates and user education on best practices.
• Regulatory compliance: Navigating the global landscape of payment regulations can be complex. From GDPR to PSP2, businesses must comply with relevant laws, especially when handling international transactions.

While digital wallets offer advantages, businesses must address adoption barriers, security concerns, and regulatory compliance. Preparing for these challenges allows for a smooth transition and mitigates potential risks.

Industries Using Digital Wallets

We’ve established how digital wallets are revolutionising the way we handle payments, making transactions faster, safer, and more convenient. There are some industries to highlight that are making the most of this technology.

Fintech

In the fintech world, digital wallets have become indispensable. For instance, Erlang Solutions collaborated with TeleWare to enhance their Re:Call app with secure instant messaging capabilities for a major UK financial services group. By integrating MongooseIM, they ensured compliance with strict regulatory requirements while improving user experience.

E-commerce

Online shopping has been transformed by digital wallets. In 2021, a quarter of all UK transactions were made using digital wallets, and this trend is expected to grow by 18.9% through 2028. Features like biometric authentication not only make the checkout process quicker but also enhance security, leading to happier customers and increased loyalty.

Gaming

Gamers love convenience, and digital wallets deliver just that. 

By consolidating various payment methods, wallets like PayPal and Google Pay make in-game purchases seamless. This ease of use not only reduces transaction fees but also keeps players engaged, boosting customer retention.

Banking

Traditional banks are catching up by integrating digital wallets into their services. These wallets often combine payment processing with features like loyalty programmes and travel card integration. Advanced security measures, including biometric authentication, ensure that customers feel secure while enjoying personalised, cashless payment solutions.

The Future of Digital Wallets

The future of digital wallets lies in innovation.

Here are just some of the trends we are poised to see shape the landscape in the next few years: 

• Integration with wearable tech: Smartwatches and fitness trackers will make payments even more convenient.
• Biometric authentication: Consumers increasingly demand convenience without sacrificing security. Biometric features such as fingerprint recognition, voice ID, and facial scans will become commonplace, providing higher protection.
• Cryptocurrency support: As digital currencies gain acceptance, more wallets are supporting crypto transactions. With over 300 million cryptocurrency users worldwide, businesses must be ready to accommodate this growing market.

You can explore even more key digital payment trends here.

Staying ahead of these trends will position your business as a forward-thinking leader in the digital economy.

To conclude

Digital wallets aren’t just another way to pay; they’re a game-changer for improving customer experience, boosting security, and driving growth. Nearly half the world’s consumers are already using them, and with transaction values expected to hit over $10 trillion by 2026, they’re becoming a must-have for businesses.

The big question for leaders isn’t whether to integrate them, but how to do it right. Now’s the perfect time to get started. By focusing on secure tech, understanding your customers, and keeping an eye on trends, you can unlock massive benefits. Erlang Solutions has the expertise to help you build digital wallet solutions that are secure and scalable. Ready to chat about your strategy? Drop us a message today.

The post Understanding Digital Wallets appeared first on Erlang Solutions.

This is your one-stop shop for discovering everything Erlang Solutions offers in MongooseIM. From insightful blog posts to services and compelling case studies, this round-up shows how MongooseIM can evolve your messaging infrastructure.

If you’re looking to understand scalable messaging solutions or are keen to learn from real-world examples, read on to discover how MongooseIM can support your strategic goals.

MongooseIM Blogs

Our experts have crafted a series of blog posts to help you explore the full potential of MongooseIM. 

Whether you’re curious about its newest features, looking for strategies to optimise your messaging systems, or seeking ways to strike a balance between innovation and sustainability, there’s something for everyone in these insightful reads.

MongooseIM 6.3: Prometheus, CockroachDB, and More by Pawel Chrzaszcz

Discover the latest updates in MongooseIM 6.3, including integration with Prometheus for advanced monitoring and the robust scalability of CockroachDB. This blog looks deep into the enhancements that make MongooseIM a leader in real-time messaging. Learn how these features can support your business’s growth by ensuring reliable, future-proof infrastructure.

Learn more about these features and how they can support your business’s growth.

5 Ways MongooseIM Provides Scalable and Future-Proof Messaging

Why should your organisation choose MongooseIM? This blog outlines five compelling reasons. Explore how MongooseIM’s architecture is designed to meet the demands of growing user bases and evolving requirements, making it the ideal choice for forward-thinking businesses.

Discover more insights in this post.

Balancing Technical Debt and Innovation by Nelson Vides

Managing technical debt is a balancing act that every tech leader faces. This article offers actionable insights into how MongooseIM helps teams strike the right balance between maintaining existing systems and driving innovation. Learn from our experience working with leading organisations to make informed decisions about your technical strategy.

Check out the full article to learn from our experience working with leading organisations.

MongooseIM Services For Your Messaging Infrastructure

At the heart of MongooseIM lies a host of services designed to optimise, scale, and simplify your messaging infrastructure. Here are some of our services that are tailored to meet the needs of modern businesses and enhance system performance.

MongooseIM Healthcheck

Ensure your MongooseIM deployment is optimised for performance, scalability, and resilience. Our MIM Healthcheck service provides a thorough assessment, offering recommendations to improve system stability and enhance user experience. 

Explore MongooseIM Healthcheck in detail.

MongooseIM Autoscaler

MongooseIM Autoscaler helps your system adapt to traffic spikes with ease. Whether your user base grows gradually or you face sudden surges, our Autoscaler ensures seamless performance, reducing downtime and costs. 

Learn more about how Autoscaler keeps your infrastructure reliable and cost-efficient.

tryMongooseIM

Curious about MongooseIM but not sure where to start? tryMongooseIM offers a hands-on introduction to the platform, allowing you to test its features and evaluate its potential for your business before committing. 

Find out how to get started with tryMongooseIM today.

MongooseIM Case Studies: Success in Action

Real-world success stories speak volumes about MongooseIM’s impact. Discover how leading organisations have leveraged MongooseIM to transform their messaging systems, achieving scalability, reliability, and innovation in competitive industries.

Pando

Pando, a leading healthcare supply chain solutions provider, turned to MongooseIM to build a robust messaging platform that could handle real-time communication at scale. 

Read the full case study to learn how our collaboration transformed their operations with a secure and scalable solution.

Beekeeper

Beekeeper’s workforce communication platform needed a messaging backbone supporting diverse global industries. With MongooseIM, they achieved the scalability, security, and reliability their customers demanded. 

Discover their success story and see how MongooseIM helped Beekeeper thrive.

If you need more

We hope this guide provided you valuable insights into the power of MongooseIM. If you’d like to discuss how MongooseIM can elevate your messaging infrastructure, don’t hesitate to get in touch.

Contact us today and start your journey toward scalable, future-proof messaging solutions.

The post MongooseIM Round-Up appeared first on Erlang Solutions.

For many years, I have heard countless justifications for keeping messaging systems closed. Many of us have tried to rationalize walled gardens for various reasons:

• Closed messaging systems supposedly enable faster progress, as there’s no need to collaborate on shared specifications or APIs. You can change course more easily.
• Closed messaging systems are better for security, spam, or whatever other risks we imagine, because owners feel they have better control of what goes in and out.
• Closed messaging systems are said to foster innovation by protecting the network owner’s investments.

But is any of this really true? Let’s take a step back and examine these claims.

A Brief History of Messaging Tools

Until the 1990s, messaging systems were primarily focused on building communities. The dominant protocol of the time was IRC (Internet Relay Chat). While IRC allowed private messaging, its main purpose was to facilitate large chatrooms where people with shared interests could hang out and interact.

In the 1990s, messaging evolved into a true communication tool, offering an alternative to phone calls. It enabled users to stay in touch with friends and family while forging new connections online. With the limitations of the dial-up era, where users weren’t always connected, asynchronous communication became the norm. Features like offline messages and presence indicators emerged, allowing users to see at a glance who was online, available, or busy.

The revolution began with ICQ, quickly followed by competitors like Yahoo! Messenger and MSN Messenger. However, this proliferation of platforms created a frustrating experience: your contacts were spread across different networks, requiring multiple accounts and clients. Multiprotocol clients like Meebo and Pidgin emerged, offering a unified interface for these networks. Still, they often relied on unofficial protocol implementations, which were unreliable and lacked key features compared to native clients.

To address these issues, a group of innovators in 1999 set out to design a better solution—an open instant messaging protocol that revolved around two fundamental principles:

1. Federation: A federated protocol would allow users on any server to communicate seamlessly with users on other servers. This design was essential for scalability, as supporting billions of users on a single platform was unimaginable at the time.
2. Gateway Support: The protocol would include gateways to existing networks, enabling users to connect with contacts on other platforms transparently, without needing to juggle multiple applications. The gateways were implemented on the server-side, allowing fast iterations on gateway code.

This initiative, originally branded as Jabber, gave rise to XMPP (Extensible Messaging and Presence Protocol), a protocol standardized by the IETF. XMPP gained traction, with support from several open-source servers and clients. Major players adopted the protocol—Google for Google Talk and Facebook for Facebook Messenger, enabling third-party XMPP clients to connect to their services. The future of open messaging looked promising.

Fast Forward 20 Years

Today, that optimism has faded. Few people know about XMPP or its newer counterpart, Matrix. Google’s messaging services have abandoned XMPP, Facebook has closed its XMPP gateways, and the landscape has returned to the fragmentation of the past. 

Instead of Yahoo! Messenger and MSN, we now deal with WhatsApp, Facebook Messenger, Telegram, Google Chat, Signal, and even messaging features within social networks like Instagram and LinkedIn. Our contacts are scattered across these platforms, forcing us to switch between apps just as we did in the 1990s.

What Went Wrong?

Many of these platforms initially adopted XMPP, including Google, Facebook, and even WhatsApp. However, their focus on growth led them to abandon federation. Requiring users to create platform-specific accounts became a key strategy for locking in users and driving their friends to join the same network. Federation, while technically advantageous, was seen as a barrier to user acquisition and growth. 

The Big Heist

The smartphone era marked a turning point in messaging, fueled by always-on connectivity and the rise of app stores. Previously, deploying an app at scale required agreements with mobile carriers to preload the app on the phones they sold. Carriers acted as gatekeepers, tightly controlling app distribution. However, the introduction of app stores and data plans changed everything. These innovations empowered developers to bypass carriers and build their own networks on top of carrier infrastructure—a phenomenon known as over-the-top (OTT) applications. 

Among these new apps was WhatsApp, which revolutionized messaging in several ways. Initially, WhatsApp relied on Apple’s Push Notification Service to deliver messages in real time, bypassing the need for a complex infrastructure at launch. Its true breakthrough, however, was the decision to use phone numbers as user identifiers—a bold move that set a significant precedent. At the time, most messaging platforms avoided this approach because phone numbers were closely tied to SMS, and validating them via SMS codes came with significant costs.

WhatsApp cleverly leveraged this existing, international system of telecommunication identifiers to bootstrap its proprietary network. By using phone numbers, it eliminated the need for users to create, manage and share separate accounts, simplifying onboarding. WhatsApp also capitalized on the high cost of SMS at the time. Since short messages were often not unlimited, and international SMS was especially expensive, many users found it cheaper to rely on data plans or Wi-Fi to message friends and family—particularly across borders.

When we launched our own messaging app, TextOne (now discontinued), we considered using phone numbers as identifiers but ultimately decided against it. Forcing users to disclose such personal information felt intrusive and misaligned with privacy principles. By then, the phone had shifted from being a shared household device to a deeply personal one, making phone numbers uniquely tied to individual identities. 

Later, Whatsapp launched its own infrastructure based on ejabberd, but they kept their service closed. At that time, we also considered using phone number when launching our own messaging app, the now discontinued TextOne, but refused to use that. It did not feel right, as you were forcing people to disclose an important private information. As the phone had become a personnal device, instead of a household device, the phone number played the role of unique identifier for a single individual.

Unfortunately, most major players seeking to scale their messaging platforms adopted the phone number as a universal identifier. WhatsApp’s early adoption of this strategy helped it rapidly amass a billion users, giving it a decisive first-mover advantage. However, it wasn’t the only player to recognize and exploit the power of phone numbers in building massive-scale networks. Today, the phone number is arguably the most accurate global identifier for individuals, serving as a cornerstone of the flourishing data economy.

What’s Wrong With Using Phone Numbers as IDs?

Phone numbers are a common good—a foundation of global communication. They rely on the principle of universal accessibility: you can reach anyone, anywhere in the world, regardless of their phone provider or location. This system was built on international cooperation, with a branch of the United Nations playing a key role in maintaining a provider-agnostic, interoperable platform. At its core is a globally unique phone numbering system, created through collaborative standards and protocols. 

However, over-the-top (OTT) companies have exploited this infrastructure to build private networks on top of the public system. They’ve leveraged the universal identification scheme of phone numbers—and, by extension, the global interoperable network—to construct proprietary, closed ecosystems. 

To me, this feels like a misuse of a common good. Phone numbers, produced through international cooperation, should not be appropriated freely by private corporations without accountability. While it may be too late to reverse this trend, we should consider a contribution system for companies that store and use phone numbers as identifiers. 

For example, companies that maintain databases with millions of unique phone numbers could be required to pay an annual fee for each phone number they store. This fee could be distributed to the countries associated with those numbers. Such a system would achieve two things: 

1. Encourage Accountability: Companies would need to evaluate whether collecting and storing phone numbers is truly essential for their business. If the data isn’t valuable enough to justify the cost, they might choose not to collect it.
2. Promote Fairness: For companies that rely heavily on phone numbers to track, match, and build private, non-interoperable services, this fee would act as a fair contribution, akin to taxes paid for using public road infrastructure. 

It looks a lot to me that the phone number is a common good produced and use by international cooperation. It is too late to prevent it to be used by Big Tech companies. However, it may seem fair to imagine a contribution from company storing phone number. This is a data that is not their property and not theirs to use. Shouldn&apost we consider a tax on phone numbers storage and usage ? For example, if a company store a millions unique phone number in their database, why not require a yearly fee, to be paid to each country that any phone number is associated to, one yearly fee per phone number ?

Company would have to think twice about storing such personnal data. Is it valuable for your business ? If it is not valuable enough, fair enough, delete them and do not ask them, but if you need it to trakt and match user and build a private non interoperable service, then paying a fair contribution for their usage should be considered. It would be like the tax they pay to leverage road infrastructure in countries where they operate.

Beyond Taxes: The Push for Interoperability

Of course, a contribution system alone won’t solve the larger issue. We also need a significant push toward interoperable and federated messaging. While the European Digital Markets Act (DMA) includes an interoperability requirement, it doesn’t go far enough. Interoperability alone cannot address the challenges of closed ecosystems.

I’ll delve deeper into why interoperability must be paired with federation in a future article, as this is a critical piece of the puzzle.

Interoperability vs. Velocity

To conclude, I’d like to reference the introduction of the IETF SPIN draft, which perfectly encapsulates the trade-offs between interoperability and innovation:

Voice, video and messaging today is commonplace on the Internet, enabled by two distinct classes of software. The first are those provided by telecommunications carriers that make heavy use of standards, such as the Session Initiation Protocol (SIP) [RFC3261]. In this approach - which we call the telco model - there is interoperability between different telcos, but the set of features and functionality is limited by the rate of definition and adoption of standards, often measured in years or decades. The second model - the app model - allows a single entity to offer an application, delivering both the server side software and its corresponding client-side software. The client-side software is delivered either as a web application, or as a mobile application through a mobile operating system app store. The app model has proven incredibly successful by any measure. It trades off interoperability for innovation and velocity.

The downside of the loss of interoperability is that entry into the market place by new providers is difficult. Applications like WhatsApp, Facebook Messenger, and Facetime, have user bases numbering in the hundreds of millions to billions of users. Any new application cannot connect with these user bases, requiring the vendor of the new app to bootstrap its own network effects.

This summary aligns closely with the ideas I’ve explored in this article. 

I believe we’ve reached a point where we need interoperability far more than continued innovation in voice, video, and messaging. While innovation in these areas has been remarkable, we have perhaps been too eager—or too blind—to sacrifice interoperability in the name of progress. 

Now, the pendulum is poised to swing back. Centralization must give way to federation if we are to maintain the universality that once defined global communication. Without federation, there can be no true global and universal service, and without universality, we risk regressing, fragmenting all our communication systems into isolated and proprietary silos. 

It’s time to prioritize interoperability, to reclaim the vision of a truly connected world where communication is open, accessible, and universal.

Fluux is our ejabberd Business Edition cloud service. With a subscription, we deploy, manage, update and scale an instance of our most scalable messaging server. Up to now, if you wanted to deploy several services, you had to create another account with a different email. Starting today, you can manage and pay for different servers from a single Fluux account.

Here is how to use that feature. On Fluux dashboard main page after the list of your service/platforms you may have noticed a "New" button.

You will be then redirected on a page to choose your plan.

Once terms and conditions are approved, you will be able to fill your card information on a page hosted by our payment provider.

When payment is succeeded, you will be then redirected to Fluux console and a link create your service:

On this last page you will be able to provide a technical name that will be used to provision your Fluux service.

After 10 minutes you can enjoy your new service at techname.m.in-app.io (such test1.m.in-app.io in above screenshot)

The XMPP Standards Foundation’s yearly Summit will be held on January 30 and 31st, in Brussels. The Summit is an annual two-day gathering where we discuss XMPP protocol development topics. It is a place for XMPP developers to meet each other, and make progress on current issues within the protocol and ecosystem.

Immediately following the Summit is FOSDEM. FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event in Brussels.

I will be present at the Summit, and a small army of Ignite community members (including myself) will be present at FOSDEM We hope to see you at either event! If you’re around, come say hi!

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

1 post - 1 participant

Read full topic

Welcome to the first chapter of the “Elixir, 7 Steps to Start Your Journey” series. In my previous post, I discussed my journey with the programming language.

In this chapter, we will discuss the Erlang Virtual Machine, the BEAM.

To understand why the Elixir programming language is so powerful and reliable, we must understand its foundations, which means talking about Erlang. 

Elixir runs on the Erlang Virtual Machine and inherits many of its virtues. In this post, you will learn a little about the history of Erlang, the objective with which it was initially created, and why it is fundamental for Elixir.

What is Erlang?

Erlang as a programming language

Erlang is a programming language created in the mid-1980s by Joe Armstrong, Robert Virding, and Mike Williams at the Ericsson Computer Science Laboratory. Initially designed for telecommunications, it is now a general-purpose language. It was influenced by other programming languages, such as ML and Prolog, and was released as open-source in 1998.

Erlang was designed with distributed, fault-tolerant, massively concurrent, and soft real-time systems in mind, making it an excellent choice for today’s systems. Most are looking for these features, in addition to having confidence in Erlang’s history in productive systems.

Some of the characteristics of this programming language are:

• It is a declarative language, which means it is based on the principle of describing what should be calculated instead of how. 
• Pattern matching is possible at a high level and also on bit sequences.
• Functions in Erlang are first-class data.

Erlang as the development ecosystem 

Up to this point, we have referred to Erlang as the programming language; however, it should be noted that Erlang can also refer to an entire development ecosystem that is made up of:

• The Erlang programming language
• The framework OTP
• A series of tools and
• The virtual machine, BEAM

Erlang, as an ecosystem, was explicitly created to support highly available systems, which provide service even when errors or unexpected circumstances occur, and this is due to many of the characteristics of its virtual machine (VM).

So, although Erlang as a programming language is pretty cool on its own, the real magic happens when all the ecosystem elements are combined: the programming language, libraries, OTP, and the virtual machine.

If you want to know more about the history of Erlang, the list of resources below will be very helpful.

Resources

• Keynote: History of philosophy of Erlang with its creators | Code BEAM V America 2021
• 100 Years of Erlang | Quinn Wilton | Code BEAM America 2021
• Robert Virding – Hitchhiker’s Tour of the BEAM
• A brief introduction to BEAM

Erlang Virtual Machine, BEAM

The Erlang Virtual Machine, known as the BEAM, runs as an operating system process and is responsible for executing the Erlang code. It is also responsible for creating, scheduling, and managing Erlang processes, which are the fundamental basis of concurrency. 

Thanks to the BEAM schedulers, these processes can be executed in the most efficient way possible, allowing the system to be highly scalable. The processes do not share memory; they communicate through asynchronous message passing. This mechanism is the foundation for a system’s fault tolerance. As they are entirely isolated, the other system processes will not be affected if an error occurs in one of them.

The BEAM is also responsible for parallelizing your concurrent Erlang programs, making the most of a machine’s resources. Initially, the virtual machine model was a single-run queue. However, it evolved into a run queue for each available processor, ensuring no bottlenecks and that Erlang programs work correctly on any system, regardless of the number of machine cores.

Another characteristic is that storage management is automated. Garbage collection is implemented per process, which allows a system’s response time to always remain in the order of milliseconds without performance degradation.

And lastly, one of my favourite features is error detection. The virtual machine provides all the elements necessary for efficient error detection and handling, thus promoting an always-available system regardless of failures.

In summary, the BEAM is responsible for the scalability, distribution, and responsiveness of a system:

• Manages the concurrency of it.
• It has a mechanism for error detection and handling.
• Make the most of the computer’s resources.

 If you’d like to learn more about the duo that is Erlang and Elixir, check out the “What is Elixir” post.

Elixir in the BEAM

Like Erlang, Elixir was also influenced by other programming languages, including Erlang itself. Its code runs on the Erlang Virtual Machine, which means it takes advantage of all its features and can use all the Erlang libraries and the OTP framework.

Different programming languages ​​besides Elixir and Erlang run in the BEAM, but Elixir has ensured that the approach between BEAM and programmers is fluid and quickly understandable.

Elixir code is compiled into bytecode that runs in the BEAM and is more compact than Erlang code. Its syntax is similar to how we communicate daily, allowing for early familiarization with the language, even if it is the first time you program with it. It also reduces the boilerplate and has amazing documentation.

So, when writing code with Elixir, we have the best of both: a solid and battle-tested foundation that allows us to create fail-safe systems and, on the other hand, nice syntax, well-defined patterns, and code simplification, among other things. Thanks to this, Elixir has been so well accepted and has rapidly gained popularity.

Elixir is a cool programming language that allows you to write code that is easy to understand and maintain and takes advantage of the Erlang concurrency model, which we will discuss in the next chapter.

> iex


iex(1)> list = [4,5,21,1,38]


iex(2)> erlang_example = :lists.sort(list);
[1, 4, 5, 21, 38]


iex(3)> elixir_example = Enum.sort(list)
[1, 4, 5, 21, 38]

Example of how you can run Erlang and Elixir code in an interactive Elixir shell

Next chapter

In the next post, “Understanding Processes and Concurrency,” we will discuss how Erlang processes work and their importance in developing robust and scalable systems. We will also see how concurrency works in Erlang and how this relates to Elixir. Do not miss it! You can drop the team a message if you’d like to discuss Elixir in more detail.

The post The BEAM-Erlang’s virtual machine appeared first on Erlang Solutions.

The post test appeared first on Erlang Solutions.

Welcome to the first chapter of the “Elixir, 7 Steps to Start Your Journey” series. In my previous post, I discussed my journey with the programming language.

In this chapter, we will discuss the Erlang Virtual Machine, the BEAM.

To understand why the Elixir programming language is so powerful and reliable, we must understand its foundations, which means talking about Erlang. 

Elixir runs on the Erlang Virtual Machine and inherits many of its virtues. In this post, you will learn a little about the history of Erlang, the objective with which it was initially created, and why it is fundamental for Elixir.

What is Erlang?

Erlang as a programming language

Erlang is a programming language created in the mid-1980s by Joe Armstrong, Robert Virding, and Mike Williams at the Ericsson Computer Science Laboratory. Initially designed for telecommunications, it is now a general-purpose language. It was influenced by other programming languages, such as ML and Prolog, and was released as open-source in 1998.

Erlang was designed with distributed, fault-tolerant, massively concurrent, and soft real-time systems in mind, making it an excellent choice for today’s systems. Most are looking for these features, in addition to having confidence in Erlang’s history in productive systems.

Some of the characteristics of this programming language are:

• It is a declarative language, which means it is based on the principle of describing what should be calculated instead of how. 
• Pattern matching is possible at a high level and also on bit sequences.
• Functions in Erlang are first-class data.

Erlang as the development ecosystem 

Up to this point, we have referred to Erlang as the programming language; however, it should be noted that Erlang can also refer to an entire development ecosystem that is made up of:

• The Erlang programming language
• The framework OTP
• A series of tools and
• The virtual machine, BEAM

Erlang, as an ecosystem, was explicitly created to support highly available systems, which provide service even when errors or unexpected circumstances occur, and this is due to many of the characteristics of its virtual machine (VM).

So, although Erlang as a programming language is pretty cool on its own, the real magic happens when all the ecosystem elements are combined: the programming language, libraries, OTP, and the virtual machine.

If you want to know more about the history of Erlang, the list of resources below will be very helpful.

Resources

• Keynote: History of philosophy of Erlang with its creators | Code BEAM V America 2021
• 100 Years of Erlang | Quinn Wilton | Code BEAM America 2021
• Robert Virding – Hitchhiker’s Tour of the BEAM
• A brief introduction to BEAM

Erlang Virtual Machine, BEAM

The Erlang Virtual Machine, known as the BEAM, runs as an operating system process and is responsible for executing the Erlang code. It is also responsible for creating, scheduling, and managing Erlang processes, which are the fundamental basis of concurrency. 

Thanks to the BEAM schedulers, these processes can be executed in the most efficient way possible, allowing the system to be highly scalable. The processes do not share memory; they communicate through asynchronous message passing. This mechanism is the foundation for a system’s fault tolerance. As they are entirely isolated, the other system processes will not be affected if an error occurs in one of them.

The BEAM is also responsible for parallelizing your concurrent Erlang programs, making the most of a machine’s resources. Initially, the virtual machine model was a single-run queue. However, it evolved into a run queue for each available processor, ensuring no bottlenecks and that Erlang programs work correctly on any system, regardless of the number of machine cores.

Another characteristic is that storage management is automated. Garbage collection is implemented per process, which allows a system’s response time to always remain in the order of milliseconds without performance degradation.

And lastly, one of my favourite features is error detection. The virtual machine provides all the elements necessary for efficient error detection and handling, thus promoting an always-available system regardless of failures.

In summary, the BEAM is responsible for the scalability, distribution, and responsiveness of a system:

• Manages the concurrency of it.
• It has a mechanism for error detection and handling.
• Make the most of the computer’s resources.

 If you’d like to learn more about the duo that is Erlang and Elixir, check out the “What is Elixir” post.

Elixir in the BEAM

Like Erlang, Elixir was also influenced by other programming languages, including Erlang itself. Its code runs on the Erlang Virtual Machine, which means it takes advantage of all its features and can use all the Erlang libraries and the OTP framework.

Different programming languages ​​besides Elixir and Erlang run in the BEAM, but Elixir has ensured that the approach between BEAM and programmers is fluid and quickly understandable.

Elixir code is compiled into bytecode that runs in the BEAM and is more compact than Erlang code. Its syntax is similar to how we communicate daily, allowing for early familiarization with the language, even if it is the first time you program with it. It also reduces the boilerplate and has amazing documentation.

So, when writing code with Elixir, we have the best of both: a solid and battle-tested foundation that allows us to create fail-safe systems and, on the other hand, nice syntax, well-defined patterns, and code simplification, among other things. Thanks to this, Elixir has been so well accepted and has rapidly gained popularity.

Elixir is a cool programming language that allows you to write code that is easy to understand and maintain and takes advantage of the Erlang concurrency model, which we will discuss in the next chapter.

> iex


iex(1)> list = [4,5,21,1,38]


iex(2)> erlang_example = :lists.sort(list);
[1, 4, 5, 21, 38]


iex(3)> elixir_example = Enum.sort(list)
[1, 4, 5, 21, 38]

Example of how you can run Erlang and Elixir code in an interactive Elixir shell

Next chapter

In the next post, “Understanding Processes and Concurrency,” we will discuss how Erlang processes work and their importance in developing robust and scalable systems. We will also see how concurrency works in Erlang and how this relates to Elixir. Do not miss it! You can drop the team a message if you’d like to discuss Elixir in more detail.

The post Erlang’s virtual machine, the BEAM appeared first on Erlang Solutions.

A bit less than a year since the latest version, there has been around 45 commits to include in this new release.

We’re very excited to be back at FOSDEM in person in 2025. Once again, many members of the XSF and the XMPP community will be attending, and we hope to see you there!

Realtime Lounge

As usual, we will host the Realtime Lounge, where you can come and meet community members, project developers, see demos and ask us questions. We’ll be in our traditional location - find us on the K building 2nd floor, beside the elevator (map below). Come and say Hi! Yes, we got stickers :-)

Map of the K building level 2

Talks

There will be a presentation in the Real Time Communications (RTC) track:

• Jérôme Poisson (Goffi):
  • A Universal and Stable API to Everything: XMPP: “Nowadays, most services provide APIs with their own formats, and sometimes multiple versions, which may change over time. But there is a universal API, with an excellent track record of stability and backward compatibility: XMPP!. In this talk, I’ll show how XMPP can be more than just an Instant Messaging protocol, and how it can be an extremely powerful tool to access almost anything, from third-party networks (IM, microblogging, etc.) to file sharing, automation (IoT), and more. “. The presentation will take place on Saturday, February 1st 2025, on the Real Time Communications (RTC) track, room K.3.601, starting at 18:25 and ending at 18:40 hs.

XMPP Summit 27

Prior to FOSDEM, the XSF will also hold its 27th XMPP summit. This is where community members gather to discuss protocol changes and exchange within the developer community. We’ll be reporting live from the event and also from FOSDEM.

Spread the word

Please share the news on other networks:

• Mastodon
• Twitter
• YouTube
• LinkedIn
• Lemmy instance (unofficial)
• Reddit (unofficial)

Welcome to the first chapter of the “Elixir, 7 Steps to Start Your Journey” series. In my previous post, I discussed my personal journey with the programming language.

In this chapter, we will discuss the Erlang Virtual Machine, the BEAM.

To understand why the Elixir programming language is so powerful and reliable, we must understand its foundations, which means talking about Erlang. 

Elixir runs on the Erlang Virtual Machine and inherits many of its virtues. In this post, you will learn a little about the history of Erlang, the objective with which it was initially created, and why it is fundamental for Elixir.

What is Erlang?

Erlang as a programming language

Erlang is a programming language created in the mid-1980s by Joe Armstrong, Robert Virding, and Mike Williams at the Ericsson Computer Science Laboratory. Initially designed for telecommunications, it is now a general-purpose language. It was influenced by other programming languages, such as ML and Prolog, and was released as open-source in 1998.

Erlang was designed with distributed, fault-tolerant, massively concurrent, and soft real-time systems in mind, making it an excellent choice for today’s systems. Most are looking for these features, in addition to having confidence in Erlang’s history in productive systems.

Some of the characteristics of this programming language are:

• It is a declarative language, which means it is based on the principle of describing what should be calculated instead of how. 
• Pattern matching is possible at a high level and also on bit sequences.
• Functions in Erlang are first-class data.

Erlang as the development ecosystem 

Up to this point, we have referred to Erlang as the programming language; however, it should be noted that Erlang can also refer to an entire development ecosystem that is made up of:

• The Erlang programming language
• The framework OTP
• A series of tools and
• The virtual machine, BEAM

Erlang, as an ecosystem, was explicitly created to support highly available systems, which provide service even when errors or unexpected circumstances occur, and this is due to many of the characteristics of its virtual machine (VM).

So, although Erlang as a programming language is pretty cool on its own, the real magic happens when all the ecosystem elements are combined: the programming language, libraries, OTP, and the virtual machine.

If you want to know more about the history of Erlang, the list of resources below will be very helpful.

Resources

• Keynote: History of philosophy of Erlang with its creators | Code BEAM V America 2021
• 100 Years of Erlang | Quinn Wilton | Code BEAM America 2021
• Robert Virding – Hitchhiker’s Tour of the BEAM
• A brief introduction to BEAM

Erlang Virtual Machine, BEAM

The Erlang Virtual Machine, known as the BEAM, runs as an operating system process and is responsible for executing the Erlang code. It is also responsible for creating, scheduling, and managing Erlang processes, which are the fundamental basis of concurrency. 

Thanks to the BEAM schedulers, these processes can be executed in the most efficient way possible, allowing the system to be highly scalable. The processes do not share memory; they communicate through asynchronous message passing. This mechanism is the foundation for a system’s fault tolerance. As they are entirely isolated, the other system processes will not be affected if an error occurs in one of them.

The BEAM is also responsible for parallelizing your concurrent Erlang programs, making the most of a machine’s resources. Initially, the virtual machine model was a single-run queue. However, it evolved into a run queue for each available processor, ensuring no bottlenecks and that Erlang programs work correctly on any system, regardless of the number of machine cores.

Another characteristic is that storage management is automated. Garbage collection is implemented per process, which allows a system’s response time to always remain in the order of milliseconds without performance degradation.

And lastly, one of my favourite features is error detection. The virtual machine provides all the elements necessary for efficient error detection and handling, thus promoting an always-available system regardless of failures.

In summary, the BEAM is responsible for the scalability, distribution, and responsiveness of a system:

• Manages the concurrency of it.
• It has a mechanism for error detection and handling.
• Make the most of the computer’s resources.

 If you’d like to learn more about the duo that is Erlang and Elixir, check out the “What is Elixir” post.

Elixir in the BEAM

Like Erlang, Elixir was also influenced by other programming languages, including Erlang itself. Its code runs on the Erlang Virtual Machine, which means it takes advantage of all its features and can use all the Erlang libraries and the OTP framework.

Different programming languages ​​besides Elixir and Erlang run in the BEAM, but Elixir has ensured that the approach between BEAM and programmers is fluid and quickly understandable.

Elixir code is compiled into bytecode that runs in the BEAM and is more compact than Erlang code. Its syntax is similar to how we communicate daily, allowing for early familiarization with the language, even if it is the first time you program with it. It also reduces the boilerplate and has amazing documentation.

So, when writing code with Elixir, we have the best of both: a solid and battle-tested foundation that allows us to create fail-safe systems and, on the other hand, nice syntax, well-defined patterns, and code simplification, among other things. Thanks to this, Elixir has been so well accepted and has rapidly gained popularity.

Elixir is a cool programming language that allows you to write code that is easy to understand and maintain and takes advantage of the Erlang concurrency model, which we will discuss in the next chapter.

> iex


iex(1)> list = [4,5,21,1,38]


iex(2)> erlang_example = :lists.sort(list);
[1, 4, 5, 21, 38]


iex(3)> elixir_example = Enum.sort(list)
[1, 4, 5, 21, 38]

Example of how you can run Erlang and Elixir code in an interactive Elixir shell

Next chapter

In the next post, “Understanding Processes and Concurrency,” we will discuss how Erlang processes work and their importance in developing robust and scalable systems. We will also see how concurrency works in Erlang and how this relates to Elixir. Do not miss it! You can drop the team a message if you’d like to discuss Elixir in more detail.

The post Erlang’s virtual machine, the BEAM appeared first on Erlang Solutions.

Welcome to the first chapter of the “Elixir, 7 Steps to Start Your Journey” series. In my previous post, I discussed my personal journey with the programming language.

In this chapter, we will discuss the Erlang Virtual Machine, the BEAM.

To understand why the Elixir programming language is so powerful and reliable, we must understand its foundations, which means talking about Erlang. 

Elixir runs on the Erlang Virtual Machine and inherits many of its virtues. In this post, you will learn a little about the history of Erlang, the objective with which it was initially created, and why it is fundamental for Elixir.

What is Erlang?

Erlang as a programming language

Erlang is a programming language created in the mid-1980s by Joe Armstrong, Robert Virding, and Mike Williams at the Ericsson Computer Science Laboratory. Initially designed for telecommunications, it is now a general-purpose language. It was influenced by other programming languages, such as ML and Prolog, and was released as open-source in 1998.

Erlang was designed with distributed, fault-tolerant, massively concurrent, and soft real-time systems in mind, making it an excellent choice for today’s systems. Most are looking for these features, in addition to having confidence in Erlang’s history in productive systems.

Some of the characteristics of this programming language are:

• It is a declarative language, which means it is based on the principle of describing what should be calculated instead of how. 
• Pattern matching is possible at a high level and also on bit sequences.
• Functions in Erlang are first-class data.

Erlang as the development ecosystem 

Up to this point, we have referred to Erlang as the programming language; however, it should be noted that Erlang can also refer to an entire development ecosystem that is made up of:

• The Erlang programming language
• The framework OTP
• A series of tools and
• The virtual machine, BEAM

Erlang, as an ecosystem, was explicitly created to support highly available systems, which provide service even when errors or unexpected circumstances occur, and this is due to many of the characteristics of its virtual machine (VM).

So, although Erlang as a programming language is pretty cool on its own, the real magic happens when all the ecosystem elements are combined: the programming language, libraries, OTP, and the virtual machine.

If you want to know more about the history of Erlang, the list of resources below will be very helpful.

Resources

• Keynote: History of philosophy of Erlang with its creators | Code BEAM V America 2021
• 100 Years of Erlang | Quinn Wilton | Code BEAM America 2021
• Robert Virding – Hitchhiker’s Tour of the BEAM
• A brief introduction to BEAM

Erlang Virtual Machine, BEAM

The Erlang Virtual Machine, known as the BEAM, runs as an operating system process and is responsible for executing the Erlang code. It is also responsible for creating, scheduling, and managing Erlang processes, which are the fundamental basis of concurrency. 

Thanks to the BEAM schedulers, these processes can be executed in the most efficient way possible, allowing the system to be highly scalable. The processes do not share memory; they communicate through asynchronous message passing. This mechanism is the foundation for a system’s fault tolerance. As they are entirely isolated, the other system processes will not be affected if an error occurs in one of them.

The BEAM is also responsible for parallelizing your concurrent Erlang programs, making the most of a machine’s resources. Initially, the virtual machine model was a single-run queue. However, it evolved into a run queue for each available processor, ensuring no bottlenecks and that Erlang programs work correctly on any system, regardless of the number of machine cores.

Another characteristic is that storage management is automated. Garbage collection is implemented per process, which allows a system’s response time to always remain in the order of milliseconds without performance degradation.

And lastly, one of my favourite features is error detection. The virtual machine provides all the elements necessary for efficient error detection and handling, thus promoting an always-available system regardless of failures.

In summary, the BEAM is responsible for the scalability, distribution, and responsiveness of a system:

• Manages the concurrency of it.
• It has a mechanism for error detection and handling.
• Make the most of the computer’s resources.

 If you’d like to learn more about the duo that is Erlang and Elixir, check out the “What is Elixir” post.

Elixir in the BEAM

Like Erlang, Elixir was also influenced by other programming languages, including Erlang itself. Its code runs on the Erlang Virtual Machine, which means it takes advantage of all its features and can use all the Erlang libraries and the OTP framework.

Different programming languages ​​besides Elixir and Erlang run in the BEAM, but Elixir has ensured that the approach between BEAM and programmers is fluid and quickly understandable.

Elixir code is compiled into bytecode that runs in the BEAM and is more compact than Erlang code. Its syntax is similar to how we communicate daily, allowing for early familiarization with the language, even if it is the first time you program with it. It also reduces the boilerplate and has amazing documentation.

So, when writing code with Elixir, we have the best of both: a solid and battle-tested foundation that allows us to create fail-safe systems and, on the other hand, nice syntax, well-defined patterns, and code simplification, among other things. Thanks to this, Elixir has been so well accepted and has rapidly gained popularity.

Elixir is a cool programming language that allows you to write code that is easy to understand and maintain and takes advantage of the Erlang concurrency model, which we will discuss in the next chapter.

> iex


iex(1)> list = [4,5,21,1,38]


iex(2)> erlang_example = :lists.sort(list);
[1, 4, 5, 21, 38]


iex(3)> elixir_example = Enum.sort(list)
[1, 4, 5, 21, 38]

Example of how you can run Erlang and Elixir code in an interactive Elixir shell

Next chapter

In the next post, “Understanding Processes and Concurrency,” we will discuss how Erlang processes work and their importance in developing robust and scalable systems. We will also see how concurrency works in Erlang and how this relates to Elixir. Do not miss it! You can drop the team a message if you’d like to discuss Elixir in more detail.

The post Erlang’s virtual machine, the BEAM 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 December 2024.

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 until February 16th, 2025, 00:00 UTC!.

XMPP Summit 27 & FOSDEM 2025

The XSF is planning the XMPP Summit 27, which is to take place on January 30th & 31st 2025 in Brussels (Belgium, Europe). Following the Summit, the XSF is also planning to be present at FOSDEM 2025, which takes place on February 1st & 2nd 2025. Find all the details in our Wiki. Please sign-up now if you are planning to attend, since this helps organizing. The event is of course open for everyone interested to participate. Spread the word within your circles!

XMPP at FOSDEM 2025

• Jérôme Poisson (Goffi) presentation at FOSDEM 2025:
  • A Universal and Stable API to Everything: XMPP: “Nowadays, most services provide APIs with their own formats, and sometimes multiple versions, which may change over time. But there is a universal API, with an excellent track record of stability and backward compatibility: XMPP!. In this talk, I’ll show how XMPP can be more than just an Instant Messaging protocol, and how it can be an extremely powerful tool to access almost anything, from third-party networks (IM, microblogging, etc.) to file sharing, automation (IoT), and more. “. The presentation will take place on Saturday, February 1st 2025, on the Real Time Communications (RTC) track, room K.3.601, starting at 18:25 and ending at 18:40 hs.

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 iOS
• 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).
• PravConf 2025: PravConf 2025 is the first edition of the annual gathering of the Prav community, and it will be held on March 1, 2025, at the Model Engineering College, in Kochi. Feel free to Join the group to learn more!

Talks

• Podcast: NGI0: Next Generation Internet
  • “Technology is not neutral” - Libervia: “It is important to be able to communicate freely”, says Jérôme Poisson a.k.a. @Goffi@mastodon.social. He is the main developer of Libervia, a communication ecosystem based on XMPP. The open standard is mostly associated with chat but Libervia offers many more features such as blogs, fora, calendars and file & photo sharing. It has gateways to other open protocols like ActivityPub and email.

XMPP Articles

• Setting up XMPP (Prosody) on Debian Bookworm: A howto on setting up and running Prosody XMPP server on Debian 12, Bookworm.
• Atom Over XMPP For New Readers: XMPP as a syndication platform for news readers and all other software.

XMPP Software News

XMPP Clients and Applications

• Psi+ 1.5.2069 installer has been released.
• Conversations has released versions 2.17.5, 2.17.6 and 2.17.7 for Android.
• Monal has released versions 6.4.7 and 6.4.8 for iOS an macOS.
• Monocles Chat 2.0.3 has been released for Android. This version brings fixes, extensions, UI improvements and more.
• Cheogram has released version 2.17.2-3 for Android. Now you can use direct share, hide media, extensions, and more.
• Kaidan has released version 0.10.0 with so many features that just can’t be summarized in one sentence! There is a complete list of changes on the changelog section and a technical overview of all currently supported features for you to check out! Version 0.10.1 was released a few days later with some bugfixes.

Kaidan IM 0.10 horizontal view screenshot

XMPP Servers

• ProcessOne announces ejabberd 24.12: The “evacuate_kindly” release: Including a few improvements and bug fixes, this release comes a month and half after version 24.10, with around 60 commits to the core repository alongside a few updates in dependencies.
• Prosody IM is pleased to announce the release of version 0.12.5, a new minor release of the 0.12 stable branch. As usual, you can consult the changelog for this release, and the download instructions for many platforms on their download page.

XMPP Libraries & Tools

• QXmpp version 1.9.2 has been released.
• go-xmpp versions 0.2.8 and 0.2.9 have been released.
• go-sendxmpp versions 0.13.0 and 0.14.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.

• No XEPs proposed this month.

New

• Version 0.1.0 of XEP-0501 (Pubsub Stories).
  • Promoted to Experimental (XEP Editor: dg)
• Version 0.1.0 of XEP-0502 (MUC Activity Indicator).
  • Promoted to Experimental (XEP Editor: dg)

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.2.0 of XEP-0480 (SASL Upgrade Tasks).
  • Fix SCRAM upgrade description and XML schema. (tm)
• Version 0.1.1 of XEP-0500 (MUC Slow Mode).
  • Include first feedbacks (jl)
• Version 0.2.0 of XEP-0501 (Pubsub Stories).
  • Add pubsub#item_expire in the node configuration (tj)

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.

• Last Call for comments on XEP-0421 (Anonymous unique occupant identifiers for MUCs).
  • This Last Call shall end at the close of business on 2025-01-06
• Last Call for comments on XEP-0424 (Message Retraction).
  • This Last Call shall end at the close of business on 2025-01-06

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
• Twitter
• YouTube
• LinkedIn
• 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, 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

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.

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

Hope everyone has had a good 2024, and you’re looking forward to a better 2025!

We’re ending this year with a bugfix release for our stable 0.12 branch. This brings some general polish and a collection of fixes for various small issues people have reported in the past months.

A notable behaviour change in this release is that Prosody will no longer send delivery errors to people you have blocked. Instead it will now just silently discard messages from the blocked JID, to avoid informing them that they have been blocked - which tends to be the preference of people we have spoken with, as well as the behaviour of many other online platforms. Obviously there are trade-offs here, so the behaviour is now configurable (see the mod_blocklist documentation).

This will be among the last releases from the 0.12 branch, as we are preparing a new major release with lots of new features. Stay tuned, and happy new year!

A summary of changes in this release:

Fixes and improvements

• mod_blocklist: Drop blocked messages without error, option to restore compliant behavior

Minor changes

• core.certmanager: Validate that ‘tls_profile’ is one of the valid values
• net.http: Throw error if missing TLS context for HTTPS request
• net.http.parser: Reject overlarge header section earlier
• net.http.files: Validate argument to setup function
• MUC: optimizations for broadcast of visitor presence (thanks Jitsi team)
• net.server_event: Add ‘wrapserver’ API
• scansion: Enable blocklist compat during tests to fix CI
• prosodyctl check: Warn about invalid domain names in the config file
• util.prosodyctl.check: Correct modern replacement for ‘disallow_s2s’
• util.prosodyctl.cert: Ensure old cert is moved out of the way
• util.prosodyctl.check: Improve error handling of UDP socket setup (for #1803)
• mod_smacks: Destroy timed out session in async context (fixes #1884: ASYNC-01 in mod_smacks hibernation timeout)
• mod_invites: Fix traceback when token_info isn’t set
• mod_admin_shell: Allow matching on host or bare JID in c2s:show
• mod_admin_adhoc: Fix log messages for reloading modules.
• core.moduleapi: Default labels to empty list to fix error if omitted
• mod_muc_mam: Improve wording of enable setting
• mod_bookmarks: Suppress error publishing empty legacy bookmarks w/ no PEP node
• mod_bookmarks: Clarify log messages on failure to sync to modern PEP bookmarks
• mod_invites_adhoc: Fix result form type (thanks betarays)
• mod_disco: Advertise disco#info and #items on bare JIDs to fix #1664: mod_disco on account doesn’t return disco#info feature
• util.xtemplate: Fix error on applying each() to zero stanzas

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!

Here comes ejabberd 24.12, including a few improvements and bug fixes. This release comes a month and half after 24.10, with around 60 commits to the core repository alongside a few updates in dependencies.

Release Highlights:

• XEP-0484: Fast Authentication Streamlining Tokens: Reduce the time it takes for authentication. This helps with a faster start for clients on mobile.
• Deprecation schedule for Erlang/OTP older than 25.0
• Commands API v3: We paved the way for API changes and improvements while allowing customers depending on older version to stay on a pinned version of the commands.

Among them, the evacuate_kindly command is a new tool which gave the funny codename to this release. It lets you stop and rerun ejabberd without letting users reconnect to let you perform your maintenance task peacefully. So, this is not an emergency exit from ejabberd, but instead testimony that this releasing is paving the way for a lot of new cool stuff in 2025.

In the meantime, we wish you a Merry Christmas and a Happy New Year!

Other contents:

• Improvements in commands
• Use non-standard STUN port
• Disable the systemd watchdog by default
• Define macro as environment variable
• Elixir modules for authentication
• Redis now supports Unix Domain Socket
• New evacuate_kindly command
• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 24.12 download & feedback

If you are upgrading from a previous version, there are no required changes in the SQL schemas, configuration or hooks. There are some Commands API v3.

Below is a detailed breakdown of the improvements and enhancements:

XEP-0484: Fast Authentication Streamlining Tokens

We added support for XEP-0484: Fast Authentication Streamlining Tokens. This allows clients to request time limited tokens from servers, which then can be later used for faster authentication by requiring less round trips. To enable this feature, you need to add mod_auth_fast module in modules section.

Deprecation schedule for Erlang/OTP older than 25.0

It is expected that around April 2025, GitHub Actions will remove Ubuntu 20 and it will not be possible to run automatically dynamic tests for ejabberd using Erlang/OTP older than 25.0.

For that reason, the planned schedule is:

• ejabberd 24.12

  • Usage of Erlang/OTP older than 25.0 is still supported, but discouraged
  • Anybody still using Erlang 24.3 down to 20.0 is encouraged to upgrade to a newer version. Erlang/OTP 25.0 and higher are supported. For instance, Erlang/OTP 26.3 is used for the binary installers and container images.

• ejabberd 25.01 (or later)

  • Support for Erlang/OTP older than 25.0 is deprecated
  • Erlang requirement softly increased in configure.ac
  • Announce: no warranty ejabberd can compile, start or pass the Common Tests suite using Erlang/OTP older than 25.0
  • Provide instructions for anybody to manually re-enable it and run the tests

• ejabberd 25.01+1 (or later)

  • Support for Erlang/OTP older than 25.0 is removed completely in the source code

Commands API v3

This ejabberd 24.12 release introduces ejabberd Commands API v3 because some commands have changed arguments and result formatting. You can continue using API v2; or you can update your API client to use API v3. Check the API Versions History.

Some commands that accepted accounts or rooms as arguments, or returned JIDs, have changed their arguments and results names and format to be consistent with the other commands:

• Arguments that refer to a user account are now named user and host
• Arguments that refer to a MUC room are now named room and service
• As seen, each argument is now only the local or server part, not the JID
• On the other hand, results that refer to user account or MUC room are now the JID

In practice, the commands that change in API v3 are:

• get_room_affiliations
• muc_register_nick
• muc_unregister_nick
• set_room_affiliation
• status_list
• status_list_host
• subscribe_room
• subscribe_room_many
• unsubscribe_room

If you want to update ejabberd to 24.12, but prefer to continue using an old API version with mod_http_api, you can set this new option:

modules:
  mod_http_api:
    default_version: 2

Improvements in commands

There are a few improvements in some commands:

• create_rooms_file: Improved, now it supports vhosts with different config
• evacuate_kindly: New command to kick users and prevent login (#4309)
• join_cluster: Improved explanation: this returns immediately (since 5a34020, 24.06)
• mod_muc_admin: Renamed arguments name to room for consistency, with backwards support (no need to update API clients)

Use non-standard STUN port

STUN via UDP can easily be abused for reflection/amplification DDoS attacks. Suggest a non-standard port to make it harder for attackers to discover the service in ejabberd.yml.example.

Modern XMPP clients discover the port via XEP-0215, so there&aposs no advantage in sticking to the standard port.

Disable the systemd watchdog by default

Some users reported ejabberd being restarted by systemd due to missing watchdog pings despite the actual service operating just fine. So far, we weren&apost able to track down the issue, so we&aposll no longer enable the watchdog in our example service unit.

Define macro as environment variable

ejabberd allows you to define macros in the configuration file since version 13.10. This allows to define a value once at the beginning of the configuration file, and use that macro to setup options values several times during the file.

Now it is possible to define the macro value as an environment variable. The environment variable name should be EJABBERD_MACRO_ + macro name.

For example, if you configured in ejabberd.yml:

define_macro:
  LOGLEVEL: 4

loglevel: LOGLEVEL

Now you can define (and overwrite) that macro definition when starting ejabberd. For example, if starting ejabberd in interactive mode:

EJABBERD_MACRO_LOGLEVEL=5 make relive

This is specially useful when using containers with slightly different values (different host, different port numbers...): instead of having a different configuration file for each container, now you can use a macro in your custom configuration file, and define different macro values as environment variable when starting each container. See some examples usages in CONTAINER&aposs composer examples

Elixir modules for authentication

ejabberd modules can be written in the Elixir programming language since ejabberd 15.02. And now, ejabberd authentication methods can also be written in Elixir!

This means you can write a custom authentication method in Erlang or in Elixir, or write an external authentication script in any language you want.

There&aposs an example authentication method in the lib/ directory. Place your custom authentication method in that directory, compile ejabberd, and configure it in ejabberd.yml:

auth_method: &aposEjabberd.Auth.Example&apos

For consistency with that file naming scheme, the old mod_presence_demo.ex has been renamed to mod_example.ex. Other minor changes were done on the Elixir example code.

Redis now supports Unix Domain Socket

Support for Unix Domain Socket was added to listener&aposs port option in ejabberd 20.07. And more recently, ejabberd 24.06 added support in sql_server when using MySQL or PostgreSQL.
That feature is useful to improve performance and security when those programs are running on the same machine as ejabberd.

Now the redis_server option also supports Unix Domain Socket.

The syntax is similar to the other options, simply setup unix: followed with the full path to the socket file. For example:

redis_server: "unix:/var/run/redis/redis.socket"

Additionally, we took the opportunity to update from the wooga/eredis erlang library which hasn&apost been updated in the last six years, to the Nordix/eredis fork which is actively maintained.

New evacuate_kindly command

ejabberd has nowadays around 180 commands to perform many administrative tasks. Let&aposs review some of their usage cases:

• Did you modify the configuration file? Reload the configuration file and apply its changes

• Did you apply some patch to ejabberd source code? Compile and install it, and then update the module binary in memory

• Did you update ejabberd-contrib specs, or improved your custom module in .ejabberd-module? Call module_upgrade to compile and upgrade it into memory

• Did you upgrade ejabberd, and that includes many changes? Compile and install it, then restart ejabberd completely

• Do you need to stop a production ejabberd which has users connected? stop_kindly the server, informing users and rooms

• Do you want to stop ejabberd gracefully? Then simply stop it

• Do you need to stop ejabberd immediately, without worrying about the users? You can halt ejabberd abruptly

Now there is a new command, evacuate_kindly, useful when you need ejabberd running to perform some administrative task, but you don&apost want users connected while you perform those tasks.

It stops port listeners to prevent new client or server connections, informs users and rooms, and waits a few seconds or minutes, then restarts ejabberd. However, when ejabberd is started again, the port listeners are stopped: this allows to perform administrative tasks, for example in the database, without having to worry about users.

For example, assuming ejabberd is running and has users connected. First let&aposs evacuate all the users:

ejabberdctl evacuate_kindly 60 \"The server will stop in one minute.\"

Wait one minute, then ejabberd gets restarted with connections disabled.
Now you can perform any administrative tasks that you need.
Once everything is ready to accept user connections again, simply restart ejabberd:

ejabberdctl restart

Acknowledgments

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

• Holger Weiß for PEP and other fixes
• Marcos de Vera Piquero for Elixir auth support
• Mark Zealey for WebSockets fix
• Mr. EddX, updated the Bulgarian translation
• Nautilusx, updated the German translation
• ButterflyOfFire, updated the French translation
• Ermete Melchiorre, updated the Italian translation
• Wellington Uemura, updated the Portuguese (Brazil)
• Besnik Bleta, updated the Albanian translation
• Sketch6580, updated the Chinese translation

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

Improvements in ejabberd Business Edition

Customers of the ejabberd Business Edition, in addition to all those improvements and bugfixes, also get support for Prometheus.

Prometheus support

Prometheus can now be used as a backend for mod_mon in addition to statsd, influxdb, influxdb2, datadog and dogstatsd.

You can expose all mod_mon metrics to Prometheus by adding a http listener pointing to mod_prometheus, for example:

  -
    port: 5280
    module: ejabberd_http
    request_handlers:
      "/metrics": mod_prometheus

You can then add a scrape config to Prometheus for ejabberd:

scrape_configs:
  - job_name: "ejabberd"
    static_configs:
      - targets:
          - "ejabberd.domain.com:5280"

You can also limit the metrics to a specific virtual host by adding it&aposs name to the path:

scrape_configs:
  - job_name: "ejabberd"
    static_configs:
      - targets:
          - "ejabberd.domain.com:5280"
     metrics_path: /metrics/myvhost.domain.com

Fix

• PubSub: fix issue on get_item_name with p1db storage backend.

ChangeLog

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

Miscelanea

• Elixir: support loading Elixir modules for auth (#4315)
• Environment variables EJABBERD_MACRO to define macros
• Fix problem starting ejabberd when first host uses SQL, other one mnesia
• HTTP Websocket: Enable allow_unencrypted_sasl2 on websockets (#4323)
• Relax checks for channels bindings for connections using external encryption
• Redis: Add support for unix domain socket (#4318)
• Redis: Use eredis 1.7.1 from Nordix when using mix/rebar3 and Erlang 21+
• mod_auth_fast: New module with support XEP-0484: Fast Authentication Streamlining Tokens
• mod_http_api: Fix crash when module not enabled (for example, in CT tests)
• mod_http_api: New option default_version
• mod_muc: Make rsm handling in disco items, correctly count skipped rooms
• mod_offline: Only delete offline msgs when user has MAM enabled (#4287)
• mod_priviled: Handle properly roster iq
• mod_pubsub: Send notifications on PEP item retract
• mod_s2s_bidi: Catch extra case in check for s2s bidi element
• mod_scram_upgrade: Don&apost abort the upgrade
• mod_shared_roster: The name of a new group is lowercased
• mod_shared_roster: Get back support for groupid@vhost in displayed

Commands API

• Change arguments and result to consistent names (API v3)
• create_rooms_file: Improve to support vhosts with different config
• evacuate_kindly: New command to kick users and prevent login (#4309)
• join_cluster: Explain that this returns immediately (since 5a34020, 24.06)
• mod_muc_admin: Rename argument name to room for consistency

Documentation

• Fix some documentation syntax, add links to toplevel, modules and API
• CONTAINER.md: Add kubernetes yaml examples to use with podman
• SECURITY.md: Add security policy and reporting guidelines
• ejabberd.service: Disable the systemd watchdog by default
• ejabberd.yml.example: Use non-standard STUN port

WebAdmin

• Shared group names are case sensitive, use original case instead of lowercase
• Use lowercase username and server authentication credentials
• Fix calculation of node&aposs uptime days
• Fix link to displayed group when it is from another vhost

Full Changelog

https://github.com/processone/ejabberd/compare/24.10...24.12

ejabberd 24.12 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.