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 BEAM – Erlang’s Virtual Machine 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 .

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 .

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.

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