ejabberd 23.10 has a new feature that is currently in beta testing:
Automatic relational schema creation and update.

Previously, if you were using ejabberd with an external relational database , you might have to manually apply some schema changes that come with new features when you upgrade to a new ejabberd release. ejabberd can now handle this schema upgrade automatically. It can also create the schema on an empty database during a new deployment. It works with both old and new schemas .

This feature paves the way for more changes to our schema in the future. It is currently in beta testing, we recommend backing up your database before using it. To enable it in ejabberd 23.10, set this top-level option in your ejabberd.yml configuration file and restart ejabberd:

update_sql_schema: true

This is compatible with the following relational databases:

• MySQL
• PostgreSQL
• SQLite

Feel free to test it and report any problems on GitHub Issues .

The post Automatic schema update in ejabberd first appeared on ProcessOne .

After I performed a release of an Openfire plugin yesterday, @akrherz apparently had a ‘hold-my-beer’ moment, and apparently went through all of our plugins source repositories, creating maintenance releases for pretty much every one of them that had outstanding changes.

Wow!

As I do not believe we’re doing anyone a favor with 16 individual blog posts, I have combined all release notifications in this one.

Most of these changes are minor: many of them add no functional change, but were needed to keep our build systems happy. Various plugins have new translations, provided by various community members (through the translation service provided by Transifex ). Thank you!

The list of changes contains 18 plugins, 16 of which were updated, while 2 were archived. Here goes!

Version 1.8.0 of the Registration plugin was released. The registration plugin allows admins to configure various actions whenever a new user creates an account. In this release, the reCaptcha implementation was replaced with Google’s reCAPTCHA v3 and various smaller improvements have been applied.

Version 1.0.1 of the MUC Service Discovery Extensions plugin was released. This plugin for Openfire allows an admin to configure Extended Service Discovery information to Multi User Chat entities (chat rooms). This can be useful if you’re working on an XMPP-based application that uses chat rooms for more than regular chat functionality. This release was a maintenance release, in which a testing dependency was updated.

Version 1.2.7 of the SIP Phone plugin was released. This plugin for Openfire lets you configure SIP phone support in Spark from the server. In this release the Chinese, Russian, Czech and Spanish translations are improved.

Version 1.8.2 of the Content Filter plugin was released. This plugin for Openfire allows admins to configure various actions based on message content. These actions include notifying the admin of content matches, notifying the sender that a message was rejected or masking the content withalternative content. This release was a maintenance release, with minor refactoring (that didn’t affect functionality) and a new translation for the Ukrainian language.

Version 0.0.2 of the IRMA Server plugin was released. This plugin for Openfire adds support for the privacy-friendly Yivi/IRMA identity platform . Minor bugs in the admin console page were fixed in this version.

Version 0.2.1 of the Tiki Token plugin was released. This plugin adds authentication integration between Openfire and the Tiki Wiki CMS Groupware project . This is a minor maintenance release, updating the project structure without changing functionality.

Version 1.0.1 of the Non-SASL Authentication plugin was released. TThe Non-SASL Authentication plugin provides a an implementation for authentication with Jabber servers and services using the jabber:iq:auth namespace.simple, as specified in XEP-0078: Non-SASL Authentication . This is a minor maintenance release, updating the project structure without changing functionality.

Version 1.2.2 of the Callback on offline plugin was released. This plugin for Openfire sends an Async POST request with a JSON body to a configurable URL when a message is received for a user that’s offline. This is a minor maintenance release that does not introduce functionality changes.

Version 1.0.0 of the JID Validation plugin was released. The JID Validation plugin adds JID Validation XEP-0328 capabilities to Openfire. This plugin is designed to work with various Jabber clients to allow other users to prepare and validate a given JID. This release was made to force the version numbering into the format used by our tooling, and does not introduce functional changes as compared to the earlier ‘1.0’ release.

Version 1.7.6 of the XML Debugger plugin was released. This plugin for Openfire records XMPP traffic which can be useful for debugging purposes. This is a minor maintenance release that does not introduce functionality changes.

Version 1.4.2 of the Subscription plugin was released. This plugin can be configured to automatically accept or reject subscription requests. When set to accept subscription requests users will be able to add someone to their roster (aka “Buddy List” or “Contacts”) without having to wait for a manual subscription acceptance from the requested user. Conversely, when the plugin is set to reject subscription requests users will not be able to add people to their roster. This is a minor maintenance release that does not introduce functionality changes.

Version 3.3.2 of the Packet Filter plugin was released. The packet filter plugin allows you to create rules that will block or reject certain packets to the server. In this release a Portuguese translation is added.

Version 2.7.1 of the User Import/Export plugin was released. The user import/export plugin provides a way to import and export Openfire user data via the Admin Console, compliant with XEP-0227 . The user data consists of username, password, name, email address, creation and modified date, and roster list (aka “buddy list”). This plugin also can aid in the migration of users from other Jabber/XMPP based systems to Openfire. This is a minor maintenance release, updating the project structure and adding new entries to the Openfire Admin Console for this plugin.

Version 1.2.4 of the MotD plugin was released. The MotD (Message of the Day) plugin allows admins to have a message sent to a user each time they login. In this release a French and Portuguese translation is added.

Version 1.2.4 of the STUN Server plugin was released. The STUN Server plugin provides address discovery for peer-to-peer sessions to be used for media transmission and receiving of UDP packets. It’s especially useful for clients behind NAT devices. In this release a Spanish and Portuguese translation is added.

Version 2.2.4] of the GoJara plugin was released. This plugin implements XEP-0321 Remote Roster Management , allowing components to manage user’s roster to provide a simple way to keep rosters in sync. This is a minor maintenance release, adding a Portuguese translation and updating dependencies.

We have archived the Openfire NodeJS plugin, as development of that plugin stalled, and the bundled version of NodeJS is outdated. This plugin should no longer be used.

We have archived the Openfire MUC Service plugin. This plugin was replaced long ago with the REST API plugin . Please use that instead.

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

1 post - 1 participant

Read full topic

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

It has been 667 days ago since we released the 4.7.0. That was the last time that a release was made from the same source code branch. And, that shows: we have closed almost 180 issues against this release! I’ll reserve the details for a blogpost on the 4.8.0 (non-beta) release, but some of the highlights are:

• We’ve dropped support for Java 8. The minimum requirement is Java 11 now
• A complete reimplementation of the asynchronous network stack, increasing stability and performance
• All known TLSv1.3 issues were resolved

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

We are looking for your help!

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

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

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

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

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

For other release announcements and news follow us on X / Twitter and Mastodon .

1 post - 1 participant

Read full topic

Introduction

I recently attended the inaugural Free and Open Source Software Yearly ( FOSSY ) conference where I gave a talk in the XMPP track. Though my talk was just a brief technical overview of the XMPP protocol, I also gave some quick ending remarks about why I think it’s the correct choice to use as a universal standardized chat protocol. The closing remarks were written about the XMPP protocol in particular, but they are also a reflection on free and open source software more generally. This post is an adapted form of that closing statement. If you’d like to see the original talk instead, it can be found on the Internet Archive .

Closing Remarks

Before we end, I’d like to take a little detour and make a brief observation on our role and our responsibilities as open source developers, advocates, and users. It may sound, at first, like I’ve veered off the tracks, but bear with me and it will all come back around to Open Source and XMPP in the end.

I recently read Becky Chamber’s “A Psalm for the Wild-Built”. Among the many beautiful and healing observations in the book, one phrase, stood out to me. It was possibly said in jest to make folks like us laugh, and maybe cry in equal measure. It was little more than a brief description of the main character’s mobile phone, but it resonated with me in a powerful way and I hope it will for you too:

“A reliable device, built to last a lifetime, as all computers were.”

Of course, this is clearly not how computers are designed today. Most of the time, I wouldn’t even go so far as to apply the adjective “reliable” to any of the software I use, open source or otherwise. But Utopian thinking isn’t about showing us where we are, or even portraying the world as it could be: it’s about inspiring us to apply our progressive ideals to create change.

Writing software is an inherently political act. While others choose to form hierarchical corporations that restrict access to the products of their workers labor, we choose to share our work freely and build cooperatively with others. That’s why we’re here at FOSSY. Being here is a statement of our values. Even the small, personal project thrown up on a code hosting website and built for no one but the author puts that person in a position of political power: when others use the software, the authors choices affect them. Whether its the choice to support or not support a screen reader, or the choice to use or not use a large framework that will only run on the latest-and-greatest (read: “expensive, unattainable for many”) machines. The author may not have made these choices consciously, but, over time, their effects will be felt by many never the less.

Therefore our primary responsibility as open source developers isn’t to shareholders or board members, or just to our current users and contributors: it’s to all the people who will use it tomorrow (and tomorrow, and tomorrow). Proprietary software stops working when the company behind it goes out of business, or when the operating system or architecture it was designed for becomes to expensive to maintain and starts affecting the bottom line, or when the VC money dries up. Meanwhile, the open source project, even once abandoned, can be updated and re-built a generation from now. It can be made more inclusive, it can be made more reliable, it can be made more portable. Unlike its closed-source alternatives, it’s repairable. When we chose to use or build closed-source software we are choosing convenience over repairability. It’s an understandable and powerful draw, whether we’re a user or a developer. However, when we choose to provide our software freely and build it cooperatively, we are choosing to support the future, and to reject convenience culture and disposable software.

It may be that you disagree with me and think that all software should be, as your license likely states, “provided as-is” without any responsibility on the part of the developer, and that’s fine. However you feel though, by writing the software you are sending a message to many people. Whether you like it or not, some will interpret it one way, some will interpret it another. The next time you open your laptop I hope you’ll think about what message you intend to send, and how it will be perceived. This is the essence of communication.

This is why I choose to use XMPP over the many proprietary or venture capital funded alternatives that come and go every day. However, as someone reminded me in the bar last night, being open source is itself necessary, but not sufficient . Our software will last far longer than its proprietary, or open-source but VC funded counterparts, and the decisions we make will reach much further into the future than even the largest companies can ever hope to achieve. Take pride in that, and build your software to reflect your values: build it to last.

Thank you for your time, and enjoy the rest of the XMPP track, and the rest of the conference.

Special Thanks

Unfortunately I was running over time and ended up skipping the Q&A portion and my last few slides. Unrealized by me at the time, this included a thank you to the organization that sponsored me to be there: Cheogram . Cheogram is a bridge between the XMPP network and the telephone network, allowing you to send text messages and make calls from any XMPP client. They also run the phone company jmp.chat where you can get a phone number or SIM card and associate it with your XMPP account without doing all the work of setting it up yourself. If you end up using them, please consider using my registration code so we can both get a free month, and thanks again to Cheogram for sending me to the conference!

For one free month, my referral code for jmp.chat is BC6ZHFMA

As sustainable programming practices continue to become the norm across the software development industry, we take a look at the future sustainability trends all businesses should be aware of.

Future sustainability changes are now impacting almost every sector worldwide, and both the wider tech sector and programming as a profession aren’t exempt from this trend. As everyone continues to work towards greener practices, a number of increasingly important trends in sustainable programming are emerging.
Below, we’ve highlighted some of the most significant future sustainability trends to help programmers, and businesses reliant on new or existing software, better understand how coding with languages like Erlang will evolve in the coming years.

1. Increased Awareness of Sustainable Programming and Implementation of Greener Strategies

The first main future sustainability trend in programming is an important one, as it both cements and justifies the importance of all the following trends. Programmers are all now acutely aware of the impacts of their code on the environment, and sustainable strategies are no longer simply a consideration – they’re increasingly becoming a requirement for anyone working with tech or code.

Green coding is now promoted by major global institutions like IBM , who continue to push for the standardisation of these practices. Meanwhile, significant international regulatory bodies, like the IPSASB, whose standards govern public sector accounting practices worldwide, have begun to publish guidance on using sustainability programs to report future sustainability information.

The below table hosted on MDPI also shows the huge increase in ScienceDirect publications focused on “sustainable development” in universities and other higher education institutions over the past decade. These are just three of hundreds of examples of sustainable programming becoming the norm.

It’s this increased awareness, driven by the ongoing climate crisis and significant environmental concerns across the planet, that means green programming goals aren’t just a future sustainability trend that will pass. They’re fast becoming the standard for the industry, and will continue to do so as both governments and private sectors work towards strict sustainability targets.

2. Clean, Lean and Efficient Coding: The 3 Green Coding Principles For Future Sustainability

A key shift towards future sustainability considerations in programming is what’s known as green coding. Green coding involves using reliable languages like Erlang in a way that considers the environmental impacts of processing code.

This involves 3 key approaches: Lean Code, Clean Code and Efficient Code. Though they all share similarities, each can be defined in the following way:

Lean Code. This involves making sure that code doesn’t include unnecessary elements. Each line should be functional, as this minimalism reduces the processing power needed to run code effectively.

Clean Code. Clean code should be easy for other programmers to understand. This makes collaboration between several programmers easier, which can then allow for more sustainable development.

Efficient Code. This involves optimising code so that it operates as efficiently as possible, with minimal processing. Efficient code, as well as the other two main green coding principles, are possible in part thanks to concurrent programming languages like Erlang.

If you’d like to learn more about green coding, as well as the value and business sense behind it, have a read through our previous blog post .

3. More Sustainable Blockchain Technology

Blockchain has long been a talking point in sustainable programming, as in the past these networks consumed huge amounts of energy to operate effectively. Today, updates in sustainable blockchain technology have reduced this energy consumption significantly.

Innovations will likely continue to ensure blockchain becomes a greener and more efficient form of technology for businesses, particularly those in certain sectors like fintech. Blockchain will also play its own important role in creating more sustainable infrastructure, as well as in more detailed reporting.

You can read more about these evolutions in blockchain’s future sustainability potential in our previous blog post .

4. Green Computing Tools

The following two major trends involve both the tools used by programmers, as well as the software they create. Green computing tools designed to monitor energy efficiency are becoming increasingly popular, as development teams need to create more efficient solutions for clients.

These future sustainability tools are sometimes created with specific programming languages in mind, like this example designed to monitor Erlang software, whilst others target specific equipment, like data centres.

Tools like these have been in development for at least a decade, as shown by the 2014 book “Green Computing: Tools and Techniques for Saving Energy, Money, and Resources”. But the number of tools available today, as well as their progressively standardised usage by programmers, makes them an important future sustainability trend for programming as a whole.

5. Future Sustainability Through Software Design

Programmers are now using languages like Erlang to contribute towards a wider initiative known as the “Greening of IT” . This is a comprehensive approach to future sustainability in tech, and a large part of its mission involves creating green software.

The initiative was started by the Green Software Foundation, which has published and maintains a training program to encourage developers to adopt greener practices.

This training also includes a list of green software engineering principles , taking into account energy efficiency, hardware efficiency and carbon awareness as well as other future sustainability concerns.

These climate considerations in programming play a key role in the profession, and will only continue to grow in importance in the years to come. With net zero by 2050 serving as a clear (and for some countries, legally binding) goal for global emissions reduction, green coding and software must continue to become more efficient.

Working Towards Future Sustainability Today With Erlang Solutions

Future sustainability isn’t tomorrow’s concern; programmers are adapting their processes right now to better support a greener future.

At Erlang Solutions, our expert team of Erlang programmers continue to modify and create new ways of working that ensure more efficient green software solutions across multiple sectors.
Thanks to its versatility, Erlang is the ideal language to support the continued shift towards future sustainability goals. If you’d like to learn more about what our team’s doing for sustainable programming, or how our Erlang support could help your business, please consider contacting our team today .

The post The Future Trends of Sustainability in Programming Software appeared first on Erlang Solutions .

In the era of the green revolution, industries across the board are gravitating towards sustainable solutions. The software realm is no exception, striving for efficient code that optimizes resource utilisation. This not only conserves energy but also minimises the environmental impact of server farms and data centers. Leading the charge in this green coding initiative are Erlang and Elixir.

These two languages, both running on the BEAM virtual machine, are renowned for:

– Superior concurrency

– Fault tolerance

– Real-time system capabilities

By leveraging these features, numerous companies have successfully reduced server consumption, paving the way for green coding solutions.

However, it’s worth noting that some existing literature doesn’t place Erlang and Elixir at the top in terms of energy efficiency. Such research often measures programming language efficiency in running various algorithms such as binary-trees or fannkuch-redux, which may not accurately represent industry usage patterns. We anticipate future studies will employ simulated environments that better mirror real-world scenarios, aligning more closely with the data we observe in practice.

In this post, we will delve into industry examples showcasing how the adoption of Erlang and Elixir has effectively cut down server usage.

WhatsApp

This globally recognised messaging app used Erlang to achieve high scalability. The power of Erlang allowed WhatsApp to handle millions of concurrent connections with a surprisingly small server cluster back in 2012.

Pinterest

Harnessing the power of Elixir, Pinterest efficiently manages around 30 thousand events every second from its 200 million active users. Thanks to the BEAM VM, they’ve streamlined their code, reducing server needs by 50% to only 15 .

Bleacher Report

Originally built on Ruby on Rails, the sports news site Bleacher Report transitioned to Elixir, resulting in substantial server reduction. From 150 servers down to just 5 , Bleacher Report achieved greater efficiency to the benefit of their profits and the environment.

Discord

Discord, the favorite communication hub for gamers, opted for Elixir to manage its real-time communication layer from day one . This strategic choice allowed Discord to serve millions of users, reducing the need for a larger server infrastructure.

AdRoll

In the world of real-time bidding where speed and efficiency are paramount, AdRoll utilized Erlang. This enabled them to handle a staggering 1.5 million bid actions per second , processing thousands of bid requests per machine. Reducing the number of servers needed with more efficient software is a prime example of green coding.

Bet365

As one of the globe’s most significant online gambling companies, Bet365 faced the herculean task of managing countless live betting scenarios. Their green solution? Erlang. This allowed them to support ten times the number of users on a single node – a win-win for the company and our planet.

In conclusion

Green coding is about harnessing technology responsibly, ensuring we make efficient use of our planet’s resources without sacrificing speed or scalability. With languages like Erlang and Elixir, we’ve seen numerous companies demonstrate that it’s possible to “have one’s cake and eat it too” in the realm of coding.

In a world grappling with climate change, every step towards sustainability counts. So the next time you embark on a coding project, remember: code not just for function, but also for the environment.

The post The Power of Green Coding: Erlang and Elixir Leading the Charge appeared first on Erlang Solutions .

This post is about a recent security incident on a public XMPP service, which provides jabber.ru and xmpp.ru. We have received a few questions from Snikket users about whether they should be concerned about the security of their own servers (Snikket also uses XMPP).

The good news is that Snikket was not affected by this incident - this was a targeted attack against the jabber.ru/xmpp.ru service specifically. Later in the post we’ll share more information about what we’ve done, and what we have planned, to ensure our systems our secure from such attacks.

What happened with jabber.ru?

It transpired yesterday that jabber.ru and xmpp.ru public XMPP services have likely been subjected to interception of their encrypted traffic for at least 90 days, and possibly up to 6 months. It is not clear who performed the interception, or why. Possibilities include law enforcement, or a compromise of the infrastructure of two hosting providers (Hetzner and Linode) used by the services.

This post won’t go into too many technical details, for which we would refer to the original write-up published here .

The “machine in the middle” (MITM) attack targeted the jabber.ru and xmpp.ru domains, and ended shortly after its discovery. We’re not aware of any documented attacks of this nature on the XMPP network before, nor indeed other internet services at this time.

Why is this news?

Although traffic interception is nothing new, previously it has mostly been performed by passively observing traffic as it passed through network devices on the internet. Snowden revealed how widespread this practice was back in 2013, prompting a large shift towards TLS encryption by default across the internet. TLS protects traffic from observers, and today it is used to protect everything you do online, from chatting, to checking your email, to online banking.

What makes this attack notable, is that it was an “active” attack - not just passing traffic through, but modifying it. Specifically, they were decrypting and re-encrypting traffic as it passed through a network device (the “machine in the middle”) that had been placed between the jabber.ru server and the rest of the internet.

Usually TLS prevents such an attack from succeeding, as long as you verify certificates. However in this case the attacker was able to obtain valid certificates for the targeted domains, making all connections look like they were genuine.

With the advent of ACME-based certificate authorities such as Let’s Encrypt, obtaining certificates is not at all hard for someone able to intercept and respond to traffic that is sent to your server, and in this case that’s exactly what happened.

How is this related to Snikket?

It’s not, mostly. However, one thing we have in common is our hosting provider - we use Hetzner for a number of our servers, including those that power Snikket Hosting .

In response to the news of this attack, we have audited all our servers and verified that none demonstrate the anomalous characteristics reported by the jabber.ru team, confirming our belief that this was targeted only at their services.

We will be taking additional steps to safeguard our systems from similar attacks, as a preventative measure. This includes:

• Deploying a strict CAA record , ensuring only our Let’s Encrypt account will be authorized to issue certificates for our hosted domains (we already have DNSSEC in place to help secure this). Update: The CAA record is now deployed.

• Setting up monitoring to alert on any suspicious certificates issued for our hosted domains. We are not currently aware of suitable tooling that would meet our needs (though there are some existing efforts in this area, such as certspotter ). If we develop anything new, we will share it with the community.

We are also currently working hard on the next Snikket Server release, which coincidentally supports the “channel binding” security feature. Channel binding is the ultimate protection against these kinds of attacks, and works even if the attacker is able to obtain a valid TLS certificate. The protection will be enabled by default on both hosted and self-hosted instances. This feature was part of our modern authentication and account security work in Prosody, funded by NGI Assure via NLnet.

Custom domains with Snikket

If you use a custom domain with your hosted Snikket instance, or if you are entirely self-hosting Snikket, you can also add a CAA record to increase security. You need to do this with your DNS provider - we cannot do it for you. We recommend using a relatively low TTL in case you make any mistakes.

Note that although it helps improve the security of your instance, setting a CAA record is entirely optional.

Custom domains on our hosting platform

If you are using our hosting platform, your CAA record contents should look like this exactly :

128 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/75887657"

You only need to set it for the main domain of your Snikket instance. If you use your domain for other things, do not add this CAA record on your root domain! E.g. If your Snikket instance is at ‘chat.example.com’, your CAA record should also be at ‘chat.example.com’. Otherwise it will prevent you from obtaining certificates for your other services.

Self-hosted instances

If you are self-hosting Snikket, you can also set a CAA record, but you will need to use your own account URI. You can run the following command in your snikket directory to find the right URI to use:

docker-compose exec snikket_server find /snikket/letsencrypt -name regr.json -exec grep uri {} +

Remember to set the CAA only on the domain or subdomain you use for Snikket. Put the URI (the part beginning with https:// ) into the record, replacing URI-GOES-HERE in the example below:

128 issue "letsencrypt.org;accounturi=URI-GOES-HERE"

After putting the CAA record in place, keep a close watch on Snikket and any other services on your domain over the following weeks, to ensure they successfully renew their certificates.

---

We hope this post has been helpful! If you have any questions about your Snikket setup, we have a helpful community chat . If you are using our hosted platform, you can also contact us via email at support@snikket.org .

A new ejabberd release, ejabberd 23.10, is now published with more than 150 commits since the previous 23.04. It includes many new features and improvements, and also many more bugfixes.

• Support for XEP-0402: PEP Native Bookmarks
• Support for XEP-0421: Occupant Id
• Many new options and features
  
  

A more detailed explanation of improvements and features:

Added support for XEP-0402: PEP Native Bookmarks

XEP-0402: PEP Native Bookmarks describes how to keep a list of chatroom bookmarks as PEP nodes on the PubSub service. That’s an improvement over XEP-0048: Bookmark Storage which described how to store in a single Private XML Storage or a single PEP node.

mod_private now supports the bookmark conversion described in XEP-0402:
ejabberd synchronizes XEP-0402 bookmarks, private storage bookmarks and XEP-0048 bookmarks.

In this sense, the bookmarks_to_pep command performs an initial synchronization of bookmarks, getting bookmarks from Private XML Storage and stores them in PEP nodes as described both in XEP-0048 and XEP-0402.

New mod_muc_occupantid module with support for XEP-0421: Occupant Id

XEP-0421: Anonymous unique occupant identifiers for MUCs is useful in anonymous MUC rooms, message correction and message retractions. Right now the only client found to support XEP-0421 is Dino , since version 0.4.

ejabberd now implements XEP-0421 0.1.0 in mod_muc_occupantid . The module is quite simple and has no configurable options: just enabled it in the modules section in your ejabberd.yml configuration file and restart ejabberd or reload_config .

New option auth_external_user_exists_check

The new option auth_external_user_exists_check makes user_check hook work better with authentication methods that don’t have a way to determine if user exists. This happens, for example, in the case of jwt and cert based authentication. As result, enabling this option improves mod_offline and mod_mam handling of offline messages to those users. This reuses information stored by mod_last for this purpose.

Improved offline messages handling when using authentication methods without users lists

Authentication methods that manage users list outside of ejabberd, like for example JWT token or tls certificate authentication, had issue with processing of offline messages. Those methods didn’t have a way to tell if given user existed when user was not logged in, and that did block processing of offline messages, which were only performed for users that we know did exists. This release adds code that also consults data stored by mod_last for that purpose, and it should fix offline messages for users that were logged at least once before.

Changes in get_roster command

There are some changes in the result output of the get_roster command defined in mod_admin_extra :

• ask is renamed to pending
• group is renamed to groups
• the new groups is a list with all the group names
• a contact that is in several groups is now listed only once, and the groups are properly listed.

For example, let’s say that admin@localhost has two contacts: a contact is present in two groups ( group1 and group2 ), the other contact is only present in a group ( group3 ).

The old get_roster command in ejabberd 23.04 and previous versions was like:

$ ejabberdctl get_roster admin localhost
jan@localhost jan   none    subscribe       group1
jan@localhost jan   none    subscribe       group2
tom@localhost tom   none    subscribe       group3

The new get_roster command in ejabberd 23.XX and newer versions returns as result:

$ ejabberdctl get_roster admin localhost
jan@localhost jan   none    subscribe       group1;group2
tom@localhost tom   none    subscribe       group3

Notice that the ejabberdctl command-line tool since now will represent list elements in results separated with ;

New halt command

Until now there were two API commands to stop ejabberd:

• stop stops ejabberd gracefully, calling to stop each of its components (client sessions, modules, listeners, …)
• stop_kindly first of all sends messages to all the online users and all the online MUC rooms, waits a few seconds, and then stops ejabberd gracefully.

Those comands are useful when there’s an ejabberd running for many time, with many users connected, and you want to stop it.

A new command is now added: halt , which abruptly stops the ejabberd node, without taking care to close gracefully any of its components. It also returns error code 1 . This command is useful if some problem is detected while ejabberd is starting.

For example, it is now used in the ecs and the ejabberd container images when CTL_ON_CREATE or CTL_ON_START were provided and failed to execute correctly. See docker-ejabberd#97 for details.

MySQL driver improvements

MySQL driver will now use prepared statements whenever possible, this should improve database load. This feature can be disabled with sql_prepared_statement: false .

We also added alternative implementation of upsert that doesn’t use replace .. or insert ... on conflict update , as in some versions of MySQL this can lead to excessive deadlocks. We switch between implementations based on version but it’s possible to override version check by having:

sql_flags:
  - mysql_alternative_upsert

inside config file.

New unix_socket listener option

When defining a listener , the port option can be a port number or a string in form "unix:/path/to/socket" to create and listen on a unix domain socket /path/to/socket .

The new unix_socket listener option allows to customize some options of that unix socket file.

The configurable options are:

• mode : which should be an octal
• owner : which should be an integer
• group : which should be an integer

Those values have no default: only when they are set, they are changed.

Example configuration:

listen:
  -
    port: "unix://tmp/asd/socket"
    unix_socket:
      mode: '0775'
      owner: 117
      group: 135

New install_contrib_modules top-level option

The new install_contrib_modules top-level option lets you declare a list of modules from ejabberd-contrib that will be installed automatically by ejabberd when it is being started. This option is read during ejabberd start or configuration reload.

This option is equivalent to installing the module manually with the command ejabberdctl module_install whatever . It is useful when deploying ejabberd automatically with a configuration file that mentions a contrib module.

For example, let’s enable and configure some modules from ejabberd-contrib, and use the new option to ensure they get installed, all of this the very first time ejabberd runs. Extract from ejabberd.yml :

...

install_contrib_modules:
  - mod_statsdx
  - mod_webadmin_config

modules:
  mod_statsdx:
    hooks: true
  mod_webadmin_config: {}
  ...

The ejabberd.log file will show something like:

2023-09-25 15:32:40.282446+02:00 [info] Loading configuration from _build/relive/conf/ejabberd.yml
Module mod_statsdx has been installed and started.
The mod_statsdx configuration in your ejabberd.yml is used.
Module mod_webadmin_config has been installed and started.
The mod_webadmin_config configuration in your ejabberd.yml is used.
2023-09-25 15:32:42.201199+02:00 [info] Configuration loaded successfully

...
2023-09-25 15:32:43.163099+02:00 [info] ejabberd 23.04.115 is started in the node ejabberd@localhost in 3.15s
2023-09-25 15:32:47.069875+02:00 [info] Reloading configuration from _build/relive/conf/ejabberd.yml
2023-09-25 15:32:47.100917+02:00 [info] Configuration reloaded successfully

New notify_on option in mod_push

mod_push has a new option: notify_on , which possible values:

• all : generate a notification on any kind of XMPP stanzas. This is the default value.
• messages : notifications are only triggered for actual chat messages with a body text (or some encrypted payload).

Add support to register nick in a room

A nick can be registered in the MUC service since ejabberd 13.06, this prevents anybody else to use that nick in any room of that MUC service.

Now ejabberd gets support to register a nick in a room, as described in XEP-0045 section 7.10 Registering with a Room

Registering a nick in the MUC service or in a room is mutually exclusive:
– A nick that is registered in the service cannot be registered in any room, not even the original owner can register it.
– Similarly, a nick registered in any room cannot be registered in the service.

MUC room option allow_private_messages converted to allowpm

Until ejabberd 23.04, MUC rooms had a configurable option called allow_private_messages with possible values true or false .

Since ejabberd 23.10, that option is converted into allowpm , with possible values:

• anyone : equivalent to allow_private_messages=true
• none : equivalent to allow_private_messages=false
• participants
• moderators

gen_mod API to simplify hooks and IQ handlers registration

If you wrote some ejabberd module, you may want to update your module to the simplified gen_mod API. This is not mandatory, because the old way to do this is supported.

Until now, erlang modules that implemented ejabberd’s gen_mod behaviour called ejabberd_hooks:add and gen_iq_handler:add_iq_handler in ther start functions. Similarly, in their stop function they called ejabberd_hooks:delete and gen_iq_hanlder:remove_iq_handler .

Since ejabberd 23.10, there is an alternative way to do this: let your start function return {ok, List} , where List is a list of iq handlers and hooks that you want your module to register to. No need to unregister them in your stop function!

How to change your module to the new API? See the changes done in mod_adhoc.erl in commit 60002fc .

MS SQL requirements

To use the Microsoft SQL Server database, the libtdsodbc library is required, as explained in the corresponding section of the ejabberd Docs: Configuration > Databases > Microsoft SQL Server

Since this release, the ejabberd container image includes this library.

Please notice if you install ejabberd using the binary installers and want to use MS SQL: you must install the libtdsodbc libraries on your machine. It cannot be included in the ejabberd installer due to the nature of the odbc drivers being dynamic depending on the respective odbc backend in use.

Erlang/OTP 20.0 or higher required

This ejabberd release requires Erlang/OTP 20.0 or newer to compile and run, support for Erlang/OTP 19.3 is deprecated. If you are still using Erlang/OTP 19.3, please update to a more recent Erlang version. For example, the ejabberd binary installers and container images are using Erlang/OTP 26.1. That requirement increase was announced almost a year ago, check more details in the ejabberd 22.10 release announcement .

If you are still using Erlang/OTP 19.3 and cannot update it right now, there’s still a possibility to compile ejabberd 23.10 with Erlang/OTP 19.3, but please notice: there is no guarantee or support that it will compile or run correctly. If interested, revert the changed line in the file configure.ac done in commit d299b97 and recompile.

Acknowledgments

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

• Holger Weiß improvements in the installers and several modules
• Saarko , improvements in the containers
• EISST International Ltd for sponsoring work on mod_push new notify_on option
• Mr. EddX , new Bulgarian translation
• Wellington Uemura , updated the Portuguese (Brazil) translation
• Олександр Кревський , updated the Ukrainian translation
• Nautilusx , updated the German 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:

• Push:
  • Add support for Webpush
  • Various APNS & GCM fixes and optimizations
  • async calls to push backends
  • Improved error messages
  • Improve error detection and reconnection strategy
  • New mod_push_logger module to log push related events
• Matrix :
  • Add support for Matrix v10 rooms
  • Add SRV support in mod_matrix_gw_s2s
• Misc:
  • Add max_concurrent_connections option to webhook
  • Add module for logging chat & jingle events in a separate file
  • Add retraction handling in MAM for p1db & dynamodb databases

ChangeLog

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

Compilation

• Erlang/OTP: Raise the requirement to Erlang/OTP 20.0 as a minimum
• CI: Update tests to Erlang/OTP 26 and recent Elixir
• Move Xref and Dialyzer options from workflows to rebar.config
• Add sections to rebar.config to organize its content
• Dialyzer dirty workarounds because re:mp() is not an exported type
• When installing module already configured, keep config as example
• Elixir 1.15 removed support for --app
• Elixir: Improve support to stop external modules written in Elixir
• Elixir: Update syntax of function calls as recommended by Elixir compiler
• Elixir: When building OTP release with mix, keep ERLANG_NODE=ejabberd@localhost
• ejabberdctl : Pass ERLANG_OPTS when calling erl to parse the INET_DIST_INTERFACE ( #4066

Commands

• create_room_with_opts : Fix typo and move examples to args_example ( #4080 )
• etop : Let ejabberdctl etop work in a release (if observer application is available)
• get_roster : Command now returns groups in a list instead of newlines ( #4088 )
• halt : New command to halt ejabberd abruptly with an error status code
• ejabberdctl : Fix calling ejabberdctl command with wrong number of arguments with Erlang 26
• ejabberdctl : Improve printing lists in results
• ejabberdctl : Support policy=user in the help and return proper arguments
• ejabberdctl : Document how to stop a debug shell: control+g
• ejabberdctl : Support policy=user in the help and return proper arguments
• ejabberdctl : Improve printing lists in results

Container

• Dockerfile: Add missing dependency for mssql databases
• Dockerfile: Reorder stages and steps for consistency
• Dockerfile: Use Alpine as base for METHOD=package
• Dockerfile: Rename packages to improve compatibility
• Dockerfile: Provide specific OTP and elixir vsn for direct compilation
• Halt ejabberd if a command in CTL_ON_ fails during ejabberd startup

Core

• auth_external_user_exists_check : New option ( #3377 )
• gen_mod : Extend gen_mod API to simplify hooks and IQ handlers registration
• gen_mod : Add shorter forms for gen_mod hook/ iq_handler API
• gen_mod : Update modules to the new gen_mod API
• install_contrib_modules : New option to define contrib modules to install automatically
• unix_socket : New listener option, useful when setting unix socket files ( #4059 )
• ejabberd_systemd : Add a few debug messages
• ejabberd_systemd : Avoid using gen_server timeout ( #4054 )( #4058 )
• ejabberd_listener : Increase default listen queue backlog value to 128, which is the default value on both Linux and FreeBSD ( #4025 )
• OAuth: Handle badpass error message
• When sending message on behalf of user, trigger user_send_packet ( #3990 )
• Web Admin: In roster page move the AddJID textbox to top ( #4067 )
• Web Admin: Show a warning when visiting webadmin with non-privileged account ( #4089 )

Docs

• Example configuration: clarify 5223 tls options; specify s2s shaper
• Make sure that policy=user commands have host instead of server arg in docs
• Improve syntax of many command descriptions for the Docs site
• Move example Perl extauth script from ejabberd git to Docs site
• Remove obsolete example files, and add link in Docs to the archived copies

Installers ( make-binaries )

• Bump Erlang/OTP version to 26.1.1, and other dependencies
• Remove outdated workaround
• Don’t build Linux-PAM examples
• Fix check for current Expat version
• Apply minor simplifications
• Don’t duplicate config entries
• Don’t hard-code musl version
• Omit unnecessary glibc setting
• Set kernel version for all builds
• Let curl fail on HTTP errors

Modules

• mod_muc_log : Add trailing backslash to URLs shown in disco info
• mod_muc_occupantid : New module with support for XEP-0421 Occupant Id ( #3397 )
• mod_muc_rtbl : Better error handling in ( #4050 )
• mod_private : Add support for XEP-0402 PEP Native Bookmarks
• mod_privilege : Don’t fail to edit roster ( #3942 )
• mod_pubsub : Fix usage of plugins option, which produced default_node_config ignore ( #4070 )
• mod_pubsub : Add pubsub_delete_item hook
• mod_pubsub : Report support of config-node-max in pep
• mod_pubsub : Relay pubsub iq queries to muc members without using bare jid ( #4093 )
• mod_pubsub : Allow pubsub node owner to overwrite items published by other persons
• mod_push_keepalive : Delay wake_on_start
• mod_push_keepalive : Don’t let hook crash
• mod_push : Add notify_on option
• mod_push : Set last-message-sender to bare JID
• mod_register_web : Make redirect to page that end with / ( #3177 )
• mod_shared_roster_ldap : Don’t crash in get_member_jid on empty output ( #3614 )

MUC

• Add support to register nick in a room ( #3455 )
• Convert allow_private_message MUC room option to allowpm ( #3736 )
• Update xmpp version to send roomconfig_changesubject in disco#info ( #4085 )
• Fix crash when loading room from DB older than ffa07c6, 23.04
• Fix support to retract a MUC room message
• Don’t always store messages passed through muc_filter_message ( #4083 )
• Pass also MUC room retract messages over the muc_filter_message ( #3397 )
• Pass MUC room private messages over the muc_filter_message too ( #3397 )
• Store the subject author JID, and run muc_filter_message when sending subject ( #3397 )
• Remove existing role information for users that are kicked from room ( #4035 )
• Expand rule “mucsub subscribers are members in members only rooms” to more places

SQL

• Add ability to force alternative upsert implementation in mysql
• Properly parse mysql version even if it doesn’t have type tag
• Use prepared statement with mysql
• Add alternate version of mysql upsert
• ejabberd_auth_sql : Reset scram fields when setting plain password
• mod_privacy_sql : Fix return values from calculate_diff
• mod_privacy_sql : Optimize set_list
• mod_privacy_sql : Use more efficient way to calculate changes in set_privacy_list

Full Changelog

https://github.com/processone/ejabberd/compare/23.04…23.10

ejabberd 23.10 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’ve found a bug, please search or fill a bug report on GitHub Issues .

The post ejabberd 23.10 first appeared on ProcessOne .