Planet Jabber

November 28, 2023

Ignite Realtime Blog

More Openfire plugin maintenance releases!

Following the initial batch of Openfire plugin releases that we did last week, another few have been made available!

Version 1.0.1 of the Spam Blacklist plugin was released. This plugin uses an external blocklist to reject traffic from specific addresses. This is a minor maintenance release that does not introduce functionality changes.

Version 1.0.0 of the EXI plugin was released. Efficient XML Interchange (EXI) is a binary XML format for exchange of data on a computer network. It is one of the most prominent efforts to encode XML documents in a binary data format, rather than plain text. Using EXI format reduces the verbosity of XML documents as well as the cost of parsing. Improvements in the performance of writing (generating) content depends on the speed of the medium being written to, the methods and quality of actual implementations. After our request for comments on this prototype, no major defects were reported. As such, we’ve decided to publish a proper release of the plugin!

Version 1.0.4 of the Email on Away plugin was released. This plugin allows to forward messages to user’s email address when the user is away (not offline). In this release, the build process was fixed. No functional changes were introduced.

Version 1.0.0 of the Push Notification plugin was released. This plugin adds support sending push notifications to client software, as described in XEP-0357: “Push Notifications”. In this release, compatibility with Openfire 4.8 was implemented.

Version 0.0.3 of the Ohùn plugin was released. This plugin implements a simple audio conferencing solution for Openfire using the Kraken WebRTC client and server. No functional changes were introduced in this release.

Version 0.0.3 of the Gitea plugin was released. This Openfire plugin adds a real-time communication to content management using a familiar GIT based workflow to create a very responsive collaboration platform that will enable an agile team to create, manage and deliver any type of content with quality assurance. IN this release, the gitea dependency was updated to 1.7.3.

Version 1.3.0 of the User Status plugin was released. This plugin automatically saves the last status (presence, IP address, logon and logoff time) per user and resource to userStatus table in the Openfire database. In this release, compatibility with Openfire 4.8 was implemented.

All of these plugins should show up in your Openfire admin console in the next few hours. You can also download them directly from their archive pages, which is linked to in the text above.

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

1 post - 1 participant

Read full topic

by guus at November 28, 2023 14:24

November 27, 2023

yaxim

Planned downtime + Happy 10th anniversary, yax.im!

Our Android XMPP client yaxim was created in 2009. A decade later, we celebrated its round birthday. To make the user experience more straightforward, we launched the yax.im public XMPP service in November 2013, to become the default server in yaxim. Now, ten years later, it’s time to recap and to upgrade the hosting infrastructure.

Downtime announcement

We will migrate the server from the old infrastructure to the new one, on Thursday, November 30th, between 8:00 and 11:00 UTC. Please expect a few hours of downtime until everything is settled!

The migration will also include an upgrade to prosody 0.12 and the deactivation of TLS v1.0 and v1.1 in favor of TLS v1.3.

Update:

  • The migration has been completed at 9:00 UTC.
  • We have re-enabled TLS v1 and v1.1, as those are still in active use.
  • We have removed offline messages archives for accounts with no activity in the last year.

/Update

Many thanks go to boerde.de for being our home for the last decade, and for enduring a few DDoS attacks on our behalf. Additional thanks go to AS250 for offering us a new home.

Ten years review

We started the service on Debian Squeeze with the freshly released Prosody 0.9 on it. Since then, there were quite a few upgrades of both the OS and of prosody. However, for technical reasons, the server is currently running on a prosody development snapshot that predates the current 0.12 major update.

In that time we’ve grown significantly, and are currently processing on average 100 thousand messages and 6.3 million presence stanzas every day.

Back in 2013, we were quite avantgarde to support not only TLSv1.0, but also v1.1 and v1.2. The support was only added into Android with the 4.1 release in 2012 and wasn’t enabled by default until 2014 with Android 5. Now we are lagging behind, given that TLS v1.3 came with Android 10 four years ago.

IRC transports

Since 2017, we are operating a beta (internal only) biboumi IRC transport on irc.yax.im and two dedicated transports for IRCnet on ircnet.yax.im and for euIRC on euirc.yax.im.

These were never officially announced and have just a few users. They will be migrated to the new host as well, but with a lower priority.

Spam fighting efforts

The XMPP spam problem has been a significant annoyance to most users. We have the opinion that XMPP spam can be best fought at the server level, where aggregate views and statistics are available, and spam can be blocked centrally for all users with mod_firewall.

In 2017, we have implemented spam detection and prevention both for yax.im users and against spam bots registered on our server. In 2020, we extended that to auto-quarantine suspicious account creations.

In the last two weeks, our spam fighting efforts have blocked 21.000 spam messages from 7.600 accounts on 72 servers, including 480 auto-flagged bot accounts on yax.im. We were not explicitly keepig note, but the number of auto-flagged accounts since the measure was introduced in 2020 is around 30.000.

As part of the JabberSPAM initiative, we have helped report abuse and bring down unmaintained spam relays.

Future

With the new hosting platform and our committed team of three administrators, we are ready to take on the challenges of the future and to sustain the growth of our user base.

November 27, 2023 15:56

Ignite Realtime Blog

New Openfire plugin: Reporting Account Affiliations

I’m excited to announce a new Openfire plugin: the Reporting Account Affiliations Plugin!

This plugin implements a new prototype XMPP extension of the same name.

To quote the specification:

In practice, a server may not trust all accounts equally. For example, if a server offers anonymous access or open registration, it may have very little trust in such users. Meanwhile a user account that was provisioned by a server administrator for an employee or a family member would naturally have a higher level of trust.

Even if a server alters its own behaviour based on how much it trusts a user account (such as preventing anonymous users from performing certain actions), other entities on the network have no way of knowing what trust to place in JIDs they have not encountered before - they can only judge the server as a whole.

This lack of insight can result in the negative actions (spam, abuse, etc.) by untrusted users on a domain causing the whole domain to be sanctioned by other servers.

This new plugin allows for Openfire to report to other entities the relationship it has with a user on its domain.

Note: at the time of writing, the protocol as implemented by this plugin has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). This plugin should be considered experimental.

The plugin will be visible in the list of available plugins of your Openfire instance in a matter of hours. You can also download it directly from its archive page.

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

1 post - 1 participant

Read full topic

by guus at November 27, 2023 14:48

November 26, 2023

Ignite Realtime Blog

Smack 4.4.7 released

We are happy to announce the release of Smack 4.4.7. For a high-level overview of what’s changed in Smack 4.4.7, check out Smack’s changelog

As with the last release, 4.4,6, parts of the release where driven by feedback from the Jitsi folks.

Due to SMACK-927, we had to change the behavior of a certain kind of incoming stanzas listeners, namely the ones added with XMPPConnection.addStanzaListener(). Before Smack 4.4.7, they where invoked outside of Smack’s main loop, now they are invoked as part of the main loop. As a result, all listeners have to finish before the main loop of the connection can continue. Consequently, if you use these kinds of listeners, make sure that they do not block, as otherwise the connection will also stop processing incoming stanzas, which can easily lead to a deadlock.

You usually should not need to use these kinds of incoming stanza listeners, alternaives include XMPPConnection.addSyncStanzaListener() and XMPPConnection.addAsyncStanzaListeners(). Especially the latter ones, asynchronous stanza listeners, are efficiently processed and safer to use. Note that those listeners are not guranteed to be processed in-order.

As always, this Smack patchlevel release is API compatible within the same major-minor version series (4.4) and all Smack releases are available via Maven Central.

We would like to use this occasion to point at that Smack now ships with a NOTICE file. Please note that this adds some requirements when using Smack as per the Apache License 2.0. The content of Smack’s NOTICE file can conveniently be retrieved using Smack.getNoticeStream().

1 post - 1 participant

Read full topic

by Flow at November 26, 2023 16:42

Gajim

Gajim 1.8.4

Gajim 1.8.4 comes with usability improvements. A shortcut for quoting previous messages has been added, and focus behavior for the message input box has been improved significantly. Thank you for all your contributions!

What’s New

If you want to quote previous messages of your chat, you can now browse previous messages by pressing Ctrl+Shift+Up/Down.

When using Gajim, you may have noticed that the message input is sometimes losing its focus when interacting with other elements, e.g., buttons on an image preview. We added some mechanisms which make sure to put the focus back on Gajim’s message input box when you start typing a message.

What else changed:

  • Group chats: Allow nick change for IRC channels
  • Improvements for password storage with multiple accounts
  • Temporary files are now removed after sending files

Have a look at the changelog for a complete list.

Gajim

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

November 26, 2023 00:00

November 22, 2023

Ignite Realtime Blog

External Service Discovery plugin 1.0.2 released!

Version 1.0.2 of the External Service Discovery plugin has been released!

This Openfire plugin allows your users to use external STUN and TURN services, optionally making use of temporary credentials for those services. It often is a prerequisite for being able to set up audio or video calls with Openfire.

This version brings better compatibility with TURN services other than those implemented by CoTurn. A big thank you for Holger and @Zoidberg for implementing and extensively testing this improvement!

Other changes include new translations for Spanish, Ukrainian, French and Portuguese and better compatibility with Java 17, while now requiring at least Java 8.

The update should be visible in the Plugins section of your Openfire admin console within the next few days. You can also download it from the plugin’s archive page.

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

1 post - 1 participant

Read full topic

by guus at November 22, 2023 19:21

XMPP Providers

XMPP Providers Automation

Automating the Automatable

During the past year, the team behind the XMPP Providers project worked on automating the process of gathering data about XMPP providers. Automating this process reduces manual work significantly (for example, checking websites by hand, verifying information, listing sources, etc.) and helps to sustain the team’s efforts. Automation also enables the project to be up to date - every day!

At the beginning of this year, work on automating the collection of several provider ‘properties’ (for example, available size for file uploads) started. An overview of all these provider properties gathered for each XMPP provider can be found on the overview page. Some of these properties were already available in a machine-readable format, making it easy to be collected.

A suite of tools has been developed since, providing the ability to query properties via XMPP and through the web. All of these tools are working together in a GitLab pipeline, which runs every night to keep the data up to date.

So far, the following properties are collected automatically:

The FAQ section explains how these properties can be provided by server admins.

More Automation

Not all of the properties collected by the XMPP Providers project are machine-readable yet. To enable automatic collection of the missing properties, the team works on extending existing standards and, if necessary, creating new ones. Due to the amount of manual work for maintaining all the provider properties, no new providers have been included in the recent past. With increasing automation and thus reduced manual intervention, the XMPP Providers project will soon be open for including new providers again!

Spread the Word

The project lives from the community and client implementations, so follow us and spread the word !

XMPP Providers Logo

XMPP Providers Logo

November 22, 2023 00:00

November 21, 2023

ProcessOne

Automatic schema update in ejabberd

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:

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

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

by Jérôme Sautret at November 21, 2023 15:11

Ignite Realtime Blog

Openfire plugin maintenance release galore!

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.

Version 1.0.3 of the Raw Property Editor plugin was released. The Raw Property Editor plugin allows admins to edit existing or add new properties to users, groups and groupchat rooms. In this release dependency was updated.

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.

3 posts - 2 participants

Read full topic

by guus at November 21, 2023 11:12

November 20, 2023

Ignite Realtime Blog

REST API Openfire plugin 1.10.2 released!

Earlier today, we have have performed a maintenance release for the REST API plugin for Openfire. In this release, version 1.10.2, we have made a warning in documentation more visible. This is aimed at reducing confusion around installation with Openfire 4.7.5.

Also in this release a translation into Ukrainian, gracefully provided by community member Yurii Savchuk (svais) and his son Vladislav Savchuk (Bruhmozavr)!

This version should pop up automatically in your list of plugins in Openfire. You can also download it from the plugin’s archive page if you want!

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

1 post - 1 participant

Read full topic

by guus at November 20, 2023 20:08

November 17, 2023

Ignite Realtime Blog

Openfire 4.8.0 beta release!

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.

6 posts - 5 participants

Read full topic

by guus at November 17, 2023 19:48

Sam Whited

Software is Political

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

Special thanks to Cheogram! Special thanks to jmp.chat!

November 17, 2023 16:41

November 09, 2023

Erlang Solutions

The Power of Green Coding: Erlang and Elixir Leading the Charge

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 optimises resource utilisation. This not only conserves energy but also minimises the environmental impact of server farms and data centres. 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 regarding energy efficiency. Such research oftenmeasures programming language efficiency in running various algorithms such as binary-trees or fannkuch-redux, which may not accurately represent industry usage patterns. Future studies will likely 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 appused Erlang to achieve high scalability. The power of Erlang allowed WhatsApp to handlemillions 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 siteBleacher Report transitioned to Elixir, resulting in substantial server reduction. From150 servers down to just 5, Bleacher Report achieved greater efficiency to the benefit of their profits and the environment

Discord

Discord, the favourite 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 utilised Erlang. This enabled them to handle a staggering1.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 supportten 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.

Embracing Green Coding

Witnessing the power of Erlang and Elixir in driving sustainability and efficiency, are you ready to transform your digital infrastructure? Join the ranks of industry leaders who are coding not just for performance, but for the planet.

Let’s collaborate to make your project eco-friendly without compromising on its capabilities.Reach out to us and start your journey towards greener coding today.

Together, we can code a better future!

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

by Simon El Nahas at November 09, 2023 11:25

November 06, 2023

Gajim

Gajim 1.8.3

Just after the release of Gajim 1.8.2, we’re releasing Gajim 1.8.3 with improvements for the profile window, fail-safes for anonymous accounts, bug fixes for the account wizard, and several other fixes. Thank you for all your contributions!

What’s New

Several issues with anonymous accounts should be resolved by improved account handling in general.

Gajim’s main window can now be closed by pressing the Esc key, if you enable closing windows via Esc in Gajim’s preferences.

What else changed:

  • Group chat participants list is shown correctly again
  • If you update your profile picture, it should now be visible in group chats without having to join again
  • Emoji short code detection has been improved

Have a look at the changelog for a complete list.

Gajim

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

November 06, 2023 00:00

November 05, 2023

The XMPP Standards Foundation

The XMPP Newsletter October 2023

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of October 2023. Many thanks to all our readers and all contributors!

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XSF Announcments

CertWatch

Recently, an XMPP service was targeted by a so-called machine-in-the-middle attack (MitM). To reduce the risk of such attacks in the future, an early stage service called CertWatch has been published by our community. This service is created and kindly provided by Stephen P. Weber (singpolyma). Find more details below.

CertWatch Logo

CertWatch Logo

XMPP Summit 26 & FOSDEM 2024

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

XMPP Vision & Strategic Workshop

Join the upcoming XMPP Vision & Strategic Workshop to discuss and understand our community better! We also asking ask for your input on different topics with focus on the future of our federated network and technology. The workshop will take place on Tuesday, 14th November 2023, 6:00 - 9:00 pm UTC. This event will take place online and will be held in English (details to follow). Everyone is welcome - please spread the word! If you have questions please write us in the XSF chat.

XMPP and Google Summer of Code 2023

The XSF has been accepted again as a hosting organisation at GSoC 2023, receiving two slots for XMPP Contributors.

On Dino:

On Moxxy:

XSF and Google Summer of Code 2023

XSF and Google Summer of Code 2023

XSF Fiscal Hosting Projects

The XSF offers fiscal hosting for XMPP projects. Please apply via Open Collective. For more information, see the announcement blog post. Current projects:

XMPP Events

Videos

Articles

In other news:

Software News

Clients and Applications

  • Two months after the last release, Gajim 1.8.2 comes with better support for gateways, improved group chats, an easy way to change the font size, and many small fixes.
  • After several months of hard work Monal 6.0 was finally released. This version comes with new artwork by Ann-Sophie Zwahlen, support for Audio-Calls funded by EU’s NGI Assure via the NLnet Foundation and many, many other improvements and bugfixes. The full list of changes can be found in this blog post.
  • monocles chat 1.7.5 to 1.7.7 have been released. monocles chat 1.7.5 is now available on F-Droid, while 1.7.7 is only available on Codeberg yet. These releases come with many design improvements to meet modern messaging clients. There are also many new settings, like custom backgrounds, the often requested option to switch between round and square avatars (in 1.7.7), and the introduction of Material Design 3. Stay tuned for a final release 1.8 in November!
  • Conversations 2.12.12 has been released, which brings support for Private DNS (DNS over TLS), a themed launcher icon, and a fix for a rare permission issue when sharing files on Android 11+.
  • Cheogram 2.12.8-3 has been released, coming with bugfixes and calling stability improvements.

Servers

Libraries & Tools

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs.

Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

  • Communicate & Ask to AI
    • This document defines a protocol for asking questions to an artificial intelligence or requesting it to make predictions.
  • HTTP Online Meetings
    • This specification defines a protocol extension to request URLs from an external HTTP entity usable to initiate and invite participants to an online meeting.

New

  • No new XEPs this month.

Deferred

If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.

  • No XEPs deferred this month.

Updated

  • Version 0.3.1 of XEP-0377 (Spam Reporting)
    • Add XML Schema. (egp)
  • Version 0.4.0 of XEP-0424 (Message Retraction)
    • Remove the dependency on XEP-0422 Message Fastening.
    • Use ‘id’ attribute on ‘retracted’ element instead of a child element.
    • Clarify business rules regarding which ‘id’ to use to refer to the retracted message. (jcb)
  • Version 0.3 of XEP-0458 (Community Code of Conduct)
    • Address substantive feedback from JC Brand; add Peter Saint-Andre as co-author to help address future feedback. (psa)

Last Call

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

  • Community Code of Conduct
    • This document describes the XMPP Standard Foundation’s Code of Conduct. This Last Call begins today and shall end at the close of business on 2023-11-30.

Stable

  • No XEP moved to stable this month.

Deprecated

  • No XEP deprecated this month.

Spread the news

Please share the news on other networks:

Subscribe to the monthly XMPP newsletter
Subscribe

Also check out our RSS Feed!

Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.

Newsletter Contributors & Translations

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

  • English (original): xmpp.org
    • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, cal0pteryx, emus, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, melvo, MSavoritias (fae,ve), nicola, XSF iTeam
  • French: jabberfr.org and linuxfr.org
    • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
  • German: xmpp.org and anoxinon.de
    • Translators: Jeybe, wh0nix
  • Italian: notes.nicfab.eu
    • Translators: nicola
  • Spanish: xmpp.org
    • Translators: daimonduff, TheCoffeMaker

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. Each month’s newsletter issue is drafted in this simple pad. At the end of each month, the pad’s content is merged into the XSF Github repository. We are always happy to welcome contributors. Do not hesitate to join the discussion in our Comm-Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.

Tasks we do on a regular basis:

  • gathering news in the XMPP universe
  • short summaries of news and events
  • summary of the monthly communication on extensions (XEPs)
  • review of the newsletter draft
  • preparation of media images
  • translations
  • communication via media accounts

License

This newsletter is published under CC BY-SA license.

November 05, 2023 00:00

hrxi

End of the Google Summer of Code 2023

This Google Summer of Code was about adding Windows/MSVC support to Dino. Dino is an XMPP client, XMPP is decentralized instant messaging standard. It is written in Vala, a programming language that integrates well with the GNOME ecosystem.

The work was started by porting Dino to the Meson build system; previously, Dino used the CMake build system. Doing this would help the Windows porting efforts, as a lot of dependencies use Meson, especially the GNOME libraries. This porting was done in dino#1453 (plus a fix in dino#1500).

As the next step, a base Dino (without any plugins) needed to be built on Windows. This first involved problems with getting Vala itself to work, and then fixing a couple of code generation issues (vala!331, vala!335 and most importantly vala!345, not yet fixed vala#1483). Meson also posed a little problem, but it could be worked around (meson#2103 comment).

Afterwards, all the dependencies needed to be ported to Windows and made compatible with Meson. For many GNOME packages, this was already the case. Many were also already in Meson’s WrapDB, a dependency manager for Meson projects. Those that haven’t found a place in WrapDB were contributed there: gee (wrapdb#1094, wrapdb#1098), gdk-pixbuf (wrapdb#1156), gtk4 (wrapdb#1206), pango (wrapdb#1207), libadwaita (wrapdb#1208), nghttp2 (wrapdb#1221), libsoup (wrapdb#1222), glib-networking (wrapdb#1223), libpsl (wrapdb#1260), libsignal-protocol-c (wrapdb#1276), qrencode (wrapdb#1277).

Some upstream bugs were also filed (libadwaita#739, libadwaita#740, wrapdb#1179, libpsl#216) or pull requests created (libsoup!381, meson#12394, libomemo-c#9).

As GnuTLS doesn’t support building in MSVC, we decided to try to replace its use with OpenSSL. This also avoided porting the complicated-to-build gpg-error. For the most part, the porting to OpenSSL was uncomplicated, however porting the DTLS/SRTP2 handshake proved non-trivial.

All in all, the most important functionality of Dino (base, http-files, omemo) works on Windows now. It still lacks polish, for example installing doesn’t work in adequately on Windows yet. The results are currently in the pr_meson_windows branch. It’s missing support for audio/video calls due to the aforementioned difficulties with OpenSSL porting.

Additionally, the goal of supporting SCRAM together with keyrings was not reached.

I’d like to thank my two mentors fiaxh and mar-v-in without whom this wouldn’t have been possible. They were quick to answer me when I struggled with problems.

I’d also like to thank my mentoring organization, the XSF (XMPP standards foundation) and especially emus who represented it for me.

by hrxi at November 05, 2023 00:00

November 02, 2023

Isode

M-Link 19.4 Limited Release

M-Link 19.4 provides a very significant update and in particular provides the M-Link User Server product. It also provides M-Link MU Server, M-Link MU Gateway and M-Link Edge.   It does not provide M-Link IRC Gateway, which remains M-Link 17.0 only.

M-Link 19.4 Limited Release is provided ahead of the full M-Link 19.4 release. M-Link 19.4 Limited Release is fully supported by Isode for production deployment. There is one significant difference with a standard Isode release:

  • Updates to M-Link 19.4 Limited Release will include additional functionality. This contrasts to standard Isode releases where updates are “bug fix only”. There will be a series of updates which will culminate in the full M-Link 19.4 release.

Goals

There are three reasons that this approach is being taken:

  1. To provide a preview for those interested to look at the new capabilities of M-Link 19.4.
  2. To enable production deployment of M-Link 19.4 ahead of full release for customers who do not need all of the features of the full M-Link 19.4 release.  M-Link 19.4 limited release provides ample functionality for a baseline XMPP user service.
  3. To enable customer review of what will be in M-Link 19.4 full release. We are planning to not provide all M-Link 17.0 capabilities in M-Link 19.4 full release. A list is provided below of the current plan. Based on feedback, we may bring more functionality into M-Link 19.4 full release. There is a trade-off between functionality and shipping date, which we will review with customers.

 

Benefits

M-Link 19.4 User Server and M-Link 19.4 MU Server offer significant benefits over M-Link 17.0:

  • M-Link 19.4 is fully Web managed, and M-Link Console is no longer used. This is the most visible difference relative to M-Link 17.0.  This enables management without installing anything on the management client.  It is helpful for deployments also using Web management in M-Link  Edge  and M-Link  MU Gateway (using either 19.3 or 19.4 versions).
  • Flexible link handling, as provided previously in M-Link 19.3
  1. Multiple links may be established with a peer.  These links may be prioritized, so that for example a SATCOM link will be used by default with fall back to HF in the event of primary link failure.  Fall forward is also supported, so that the SATCOM link is monitored and traffic will revert when it becomes available again. 
  2. Automatic closure of idle remote peer sessions after configurable period.
  3. Support for inbound only links, primarily to support Icon-Topo.
  4. “Whitespace pings” to X2X (XEP-0361) sessions to improve failover after connectivity failures.
  • M-Link MU Server allows the HF Radio improvements of M-Link 19.3 MU Gateway to be used in a single server, rather than deploying M-Link 19.3 MU Gateway plus M-Link 17.0 User Server
  • The session monitoring improvements previously provided in M-Link 19.3
  1. Shows sessions of each type (S2S, X2X (XEP-0361), GCXP (M-Link Edge), and XEP-0365 (SLEP)) with information on direction and authentication
  2. Enable monitoring for selected sessions to show traffic, including ability to monitor session initialization.
  3. Statistics for sessions, including volume of data, and number of stanzas.
  4. Peer statistics, providing summary information and number of sessions for each peer.
  5. Statistics for the whole server, giving session information for the whole server.
  • Use of the capabilities previously provided in M-Link 19.3 to provide metrics on activity to enable us to feed them into a Prometheus database using the statsd protocol. Prometheus is a widely used time series database used to store metrics:  https://prometheus.io/. Grafana is a graphing front end often used with Prometheus:  https://grafana.com/.  Grafana provides dashboards to present information.  Isode will make available sample Grafana dashboards on request to evaluators and customers.  Metrics that can be presented include:
  1. Stanza count and rate for each peer
  2. Number of bytes sent and received for each link
  3. Number of sessions (C2S; S2S; GCXP; X2X; and XEP-0365 (SLEP))
  4. Message queue size for peers – important for low bandwidth links
  5. Message latency for each peer – important for high latency links
  • Provides HTTP Upload (XEP-0363) that enables a client to upload a file to the M-Link server and then share using URL.  This is supported by Swift 6.0 to provide file sharing.
  • Enhanced FMUC (XEP-0289 Federated MUC) capabilities
    • Use of the fallback capabilities of M-Link 19.4 to provide improved resilience
    • Improved detection of failed communication between links, using (lack of) XEP-0198 acknowledgements to determine link failure and sending regular pings so that failure is detected when there is no user traffic.

M-Link 19.4 (Limited Release) Update Plan

This section sets out the plan for providing updates to M-Link 19.4 (Limited Release)

The current release is Update 1, which added FMUC capabilities among other functionality. Please note that the update number is distinct from the release version number. The first software version of update 1 is “19.4v4”.

The following updates are planned:

Update 2: Archive Administration

The initial archive capability is fully functional. Administration adds a number of functions, including the ability to export, back up and truncate the archive. These capabilities are seen as important for operational deployment of archiving.

Update 3: CSR Generation

Management of PKI identities and certificates in R19.4 is done with PEM files, which is pragmatic.  Use of PKCS#10 Certificate Signing Requests is a more elegant approach that enables operational integration with deployed Certification Authorities.

Update 4: Clustering

Clustering is the largest piece of work and the most significant omission from the limited release. It is expected to take a number of months work to complete this, based on core work already done. 

Update 5: Miscellaneous

There are a number of smaller tasks that are seen as essential for R19.4 final release, which will likely be provided incrementally. If any are seen as high priority for the limited release, it would be possible to address prior to the clustering update.

  • Server-side XEP-0346 Form Discovery and Publishing (FDP). This will enable third-party clients to use FDP.
  • Certificate checking using CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol).
  • Complete implementation of XEP-0163 Personal Eventing Protocol (PEP). This is mostly complete in the initial limited release.
  • Administration. The limited release supports single administrator with password managed by M-Link.
    • Option for multiple administrators
    • Option for administrators specified and authenticated by LDAP
    • Administrators with per-domain administration rights
  • XEP-0198 Stream Management  support for C2S (limited release supports it in S2S and XEP-0361)
  • Web monitoring of C2S connections
  • XEP-0237 Roster versioning
  • C2S SASL EXTERNAL to provide client strong authentication
  • SASL GSSAPI support to enable client authentication using Windows SSO
  • Provide transformations for C2S connections, for example to prevent negotiation of in-band bytestreams

Update 6: Upgrade

To provide an upgrade from M-Link 17.0. This capability is best developed last.

Note that M-Link 19.4 limited release will automatically upgrade from M-Link 19.2/19.3 Edge and from M-Link 19.3 MU Gateway.

Items Under Consideration for M-Link 19.4 Final Release

There is a trade-off between functionality included and ship date. The following capabilities supported in in 17.0 are under consideration for inclusion in M-Link 19.4. We ask for customer review of these items.

Unless we get clear feedback requesting inclusion of these features, we will not include them in 19.4 and will consider them as desirable features for a subsequent release.

  • XEP-0114 Jabber Component Protocol that allows use of third party components.
  • Archiving PubSub events (on user and pubsub domains)
  • Configuring what to archive per domain (R17 supports: nothing, events only (create, destroy, join, etc), events and messages)
  • Providing a clean user interface for assigning MUC affiliations to groups, to simplify MUC rights administration. This can currently be achieved but the UI is limited
  • XEP-0227 configuration support to facilitate server migration
  • “Send Announcement” to broadcast information to all users
  • PDF/A archiving to provide a simple and stable long term archive

Features post 19.4

After 19.4 Final Release is made, future releases will be provided on the normal Isode model of major and minor releases with updates as bug fix only.

Customer feedback is requested to help us set priorities for these subsequent releases.

M-Link IRC Gateway

M-Link IRC gateway is the only M-Link product not provided in M-Link 19.4. M-Link 17.0 IRC Gateway works well as an independent product.

When we do a new version, we plan to provide important new functionality and not simply move the 17.0 functionality into a new release.

New Capabilities

The R19.4 User Server focus has been to deliver functionality equivalent to 17.0 on the R19.3 base. After 19.4 we are considering adding new features. Customers are invited to provide requirements and to comment on the priority of identified potential new capabilities set out here:

  • FMUC Clustering.  M-Link 19.4 (and 17.0) FMUC nodes cannot be clustered.
  • FMUC use with M-Link IRC Gateway. Currently, IRC cannot be used with FMUC. This would be helpful for IRC deployment.
  • STANAG 4774/4778 Confidentiality Labels.
  • RFC 7395 Websocket support as an alternative to BOSH.
  • OAuth (RFC 6749) support
  • Support of PKCS#11 Hardware Security Modules

M-Link 17.0 User Server Features not in R19.4

This section sets out a number of 17.0 features that are not planned for R19.4. If there is a clear customer requirement, we could include in R19.4. We are interested in customer input on priority of these features relative to each other and to other potential work.

The following capabilities are seen to have clear benefit and Isode expects to add them.

  • Security Label and related configuration for individual MUC Rooms.  In 19.4 this can be configured per MUC domain, so an equivalent capability can be obtained by using a MUC domain for each security setting required,
  • XEP-0012 Last Activity
  • Option to limit the number of concurrent sessions for a user
  • XMPPS (port 5223) has clear security benefits. The 17.0 implementation has limited management which means that it is not generally useful in practice.

The following capabilities are potentially desirable.  Customer feedback is sought.

  • XEP-0346 Form Discovery and Publishing (FDP)
    • WebApp viewer.  We believe this would be better done in a client (e.g., Swift).
    • Gateway Java app, which converted new FDP forms to text and submitted to MUC.
    • Administration of FDP data on Server.   
  • Per-Domain Search Settings, so that users can be constrained as to which domains can be searched
  • Internal Access Control Lists, for example to permit M-Link Administrators to edit user rosters.
  • Generic PubSub administration

Features in M-Link 17.0 that Isode plans to drop

There are a number of features provided in M-Link 17.0 that Isode has no current plans to provide going forward, either because they are provided by other mechanisms or they are not seen to add value. These are listed here  primarily to validate that no customers need these functions.

  • Schematron blocking rules
    • These have been replaced with XSLT transform rules
  • IQ delegation that enables selected stanzas sent to users to be instead processed by a component
  • XEP-50 user preferences
    • This ad-hoc allowed users to set preferences overriding server defaults to indicate which types of stanzas they wanted to store in offline storage and whether to auto-accept or auto-subscribe presence.
  • Management of XEP-0191 block lists by XEP-0050 ad hoc
    • Management of block lists, where desired, is expected to be performed by XEP-0191
  • XEP-114 Component permissions
  • Pubsub presence, apart from that provided by PEP
  • XEP-78 (non-SASL authentication)
    • This is obsolete
  • Some internal APIs that are not longer needed
  • Support for a security label protocol (reverse engineered by Isode) used in the obsolete CDCIE product
  • Security Checklist
    • M-Link Console had a security checklist which checked the configuration to see if there was anything insecure
    • This does not make sense in context of the Web interface which aims to flag security issues in appropriate part of UI
  • Conversion of file based archive to Wabac
    • M-Link Console had an option to “Convert and import file-based archive…” in the “Archive” menu
    • This was needed to support archive migration from older versions of M-Link
  • Pubsub-based statistics. M-Link 17.0 recorded statistics using PubSub. M-Link 19.4 does this using Prometheus, which can be integrated with Grafana dashboards.
  • XMPP-based group discovery – the ability to use XMPP discovery on an object  and get a list of groups back.
  • XML-file archives
    • This was a write-only archive format used by older versions of M-Link before introduction of the current archive database. M-Link 17.0 continued to support this option.

by admin at November 02, 2023 12:25

Erlang Solutions

The Future Trends of Sustainability in Programming Software

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.

by Cara May-Cole at November 02, 2023 08:49

October 29, 2023

Gajim

Gajim 1.8.2

Two months after the last release, Gajim 1.8.2 comes with better support for gateways, improved group chats, an easy way to change the font size, and many small fixes. Thank you for all your contributions!

What’s New

Gateways can (if offered by your server) bridge your XMPP chat to other chat networks. This could be WhatsApp, Telegram, SMS or others, depending on the gateway service. This release improves support for data forms (service configuration), brings better avatars for gateway contacts, and improves overall integration of gateways.

Many users asked about how to change Gajim’s font size. Up until now, you could change Gajim’s conversation font size only. But now you can change Gajim’s entire user interface font size by pressing Ctrl-+ (increase), Ctrl-- (decrease), and Ctrl-0 (reset), just like you can do in web browsers.

Gajim 1.8.2

Gajim 1.8.2

What else changed:

  • Switching chats is faster now
  • On Windows, Gajim supports more media types for previews
  • You can now see who is typing a message in group chats
  • Notifications for being mentioned in a group chat are working again
  • Many other bug fixes for group chats

Have a look at the changelog for a complete list.

Gajim

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

October 29, 2023 00:00

October 24, 2023

JMP

CertWatch

As you may have already seen, on October 21st, it was reported that a long-running, successful MITM (Machine-In-The-Middle) attack against jabber.ru had been detected. The nature of this attack was not specific to the XMPP protocol in any way, but it was of special interest to us as members of the XMPP community. This kind of attack relies on being able to present a TLS certificate which anyone trying to connect will accept as valid. In this case, it was done by getting a valid certificate from Let’s Encrypt.

When it comes to mitigation strategies for client-to-server connections, luckily there is already an excellent option called channel binding. Most XMPP clients and servers already have some amount of support for this technique, and in the wake of this attack, most are scrambling to make sure their implementations are complete. Many service providers have also added CAA DNS records which can prevent the very specific way this attack was executed from succeeding.

We’ve been hard at work on a different tool that can also help with defense-in-depth for this kind of situation. Ultimately, a MITM will use a different public key from the one the server uses, even if it is wrapped in a signed certificate declared as valid by a trustworthy authority (like Let’s Encrypt). If we know what key is seen when trying to connect, and we know what key the server administrator expects us to see, we can detect an ongoing MITM of this variety even when the certificate presented is valid. The tool we have developed is in early testing now. We call it CertWatch.

The premise is simple. The server administrator knows exactly what public/private keypair they are using (or can easily find out) and publishes this in DNSSEC-signed DNS records for our tool to find. The tool then periodically polls the XMPP server over Tor to see what certificate is presented. If the key in the certificate matches the key in the DNS zone, we know the session is not MITM’d (some caveats below). CertWatch checks the current setup of any domain entered, and if not yet declaring any keys, it displays setup instructions. It will either tell you to enable DNSSEC or it will tell you which DNS records to add. Note that these records are additive, so it is safe to add multiple sets when serving multiple domains from one host through SRV records. Once everything looks good, running a domain through CertWatch will display a success message and instructions for getting notified of any issues. It will then poll the domain periodically, and if any key mismatches are found, those subscribing to notifications will receive an alert.

Some tools change your key on every certificate renewal, which means you would have to update your zone setup every time your certificates renew. Other tools allow you to reuse existing keys and save some hassle, such as certbot with the --reuse-key option.

Caveats

If we did our polls from our main server IPs, it would be easy for any attacker to detect our probes and selectively disable the MITM attack for us, making themselves invisible. Probing over Tor gives CertWatch a different IP for every request and a traffic profile almost certainly consistent with the sort that many MITM attackers are going to want to inspect. This is not perfect, however, and it may be possible to fingerprint our probes in other ways to selectively MITM some traffic and ignore others. Just because our tool’s sessions were not MITM’d does not prove that no sessions are.

Anyone with physical access to the server may also scrape the actual certificates and keys off the disk, or use similar techniques in order to execute a MITM with exactly the same key the server operator expects and would use. The particular mitigation technique CertWatch helps administrators implement is ineffective against this. Rotating the key occasionally may help, but it really depends on the sophistication of the attacker and how much access they have.

Check it Out

So head over to CertWatch, enter your service domain, and let us know what you think.

by Stephen Paul Weber at October 24, 2023 19:58

October 21, 2023

Snikket

On the jabber.ru MITM attack

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

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"

If you have a reverse proxy in front of your Snikket instance that obtains its own certificates independently from your Snikket setup, you should add an additional CAA record in the same format with the accounturi that your reverse proxy uses.

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.

by Snikket Team (team@snikket.org) at October 21, 2023 16:30

October 18, 2023

ProcessOne

ejabberd 23.10

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:

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.

by Jérôme Sautret at October 18, 2023 13:50

Erlang Solutions

Erlang Security Audit

Unlock the Power of Secure Erlang Code

Cybersecurity is a non-negotiable aspect of business. The need for robust protection extends to all aspects of your operations, including the security of your Erlang-based code. 

At Erlang Solutions, we recognise the vital importance of safeguarding your code from potential vulnerabilities and security threats. We are thrilled to introduce our latest offering – the Erlang Security Audit, just in time for this Cybersecurity Month.

Why Choose Erlang Security Audit?

The Erlang Security Audit is a comprehensive service tailored to companies relying on Erlang-based code, who are resolute in fortifying their systems against vulnerabilities and security risks. Our expertise, derived from years of experience in the field, equips us to assess your code comprehensively and ensure the utmost protection.

In-depth vulnerability assessment: The Erlang Security Audit is designed to delve deep into your code, identifying vulnerabilities and weaknesses that may make your systems susceptible to hacking and external attacks.

Up to date guidelines: Outlining the latest vulnerabilities and, more importantly, how to avoid themBusiness continuity assurance: A security breach can cripple your business, disrupt operations, and damage your reputation. Our audit ensures that your systems are fortified against threats, ensuring seamless business continuity.

How does it work?

Our Erlang Security Audit offers numerous benefits that make it the ideal choice for safeguarding your code and ensuring the uninterrupted flow of your business operations.

Code submission: You provide us with your Erlang code, and our team takes it from there.

Comprehensive analysis: We run a thorough analysis of your systems, leveraging state-of-the-art software developed in collaboration with ELTE-Soft and researchers from Eötvös Loránd University.
User-friendly reporting: We transform the analysis results into a user-friendly report, making it easy for you to understand the vulnerabilities and recommended fixes.

Please accept marketing-cookies to watch this video.

Who Should Consider Erlang Security Audit?

Companies with prior security issues: If your business has encountered security problems in the past, our audit will help you pinpoint weaknesses and strengthen your defences.

Proactive businesses: Even if you’ve had no security incidents, it’s crucial to assess your system’s vulnerabilities. Our audit uncovers potential risks before they become real threats.

Business looking for enhanced continuity: A more secure system directly contributes to better business continuity, safeguarding your operations and customer trust.

Why choose us?

Our process is designed to be seamless and efficient. You submit your Erlang code, and we take it from there. Our team, equipped with state-of-the-art software developed in collaboration with ELTE-Soft and researchers from Eötvös Loránd University, conducts a comprehensive analysis of your systems. We then transform the results into a user-friendly report, making it easy for you to understand the vulnerabilities and recommended fixes.

Collaboration with the experts: We have collaborated with ELTE-Soft and researchers from Eötvös Loránd University, a leading institution in the field, to bring you cutting-edge security analysis tools.

Erlang experts at your service: Our team comprises Erlang experts who understand the nuances of your code, ensuring a thorough assessment.

Additional support: We not only provide recommendations but also offer additional support. If your security issue is part of a larger problem, we can conduct a more extensive audit of your code and architecture to fix your system.

Timely Service: We value your time. Most security audits are completed within 2-5 days, depending on the size and complexity of your systems.

As we embrace Cybersecurity Month, remember that ensuring the security of your Erlang-based systems is a paramount concern for your business. With the Erlang Security Audit, you have a partner dedicated to fortifying your code against vulnerabilities and threats. 

Contact us today, and together, we can ensure the continuity, resilience, and trustworthiness of your business operations. Don’t wait until the threat is real – act now, and unlock the power of secure Erlang code.

The post Erlang Security Audit appeared first on Erlang Solutions.

by Erlang Admin at October 18, 2023 12:48

MongooseIM Health-Check

Optimise Your Current Deployment with a MongooseIM Health Check

MongooseIM plays a key role in today’s evolving digital landscape. For businesses, it ensures seamless communication within your organisation or application. However, like any other system, it requires regular check-ups to maintain peak performance. 

Enter the MongooseIM Health Check from our team at Erlang Solutions – your ticket to a more efficient messaging environment.

What is a MongooseIM Health Check

A MongooseIM Health Check is a thorough evaluation of your MongooseIM cluster. Its purpose is to determine if your deployment is running smoothly, correctly configured, and optimised for peak performance. Think of it like a visit to the doctor for your messaging system.

What’s Included in the MongooseIM Health Check

Our team of expert MongooseIM consultants will conduct a comprehensive review, providing you with a detailed report that includes:

Technical state overview: This section covers essential information, such as the software version, integrated components, client applications, and cluster setup characteristics.

MongooseIM configuration review: We’ll identify unused entries and suggest more efficient configurations for your server.

Testing and deployment practices: Our experts will review your testing procedures and results to eliminate bugs and bottlenecks.

Infrastructure monitoring: MongooseIM generates valuable metrics, and we’ll help you interpret them to gain insights into your system’s performance.

Recommendations and action points: We’ll summarise our findings and provide a prioritised list of action items to enhance your MongooseIM deployment.

Who Can Benefit

This service caters to diverse needs, making it a valuable resource for various individuals and organisations. 

Firstly, it is a boon for businesses that have already implemented MongooseIM, whether in the development phase or have a fully operational production environment. It offers you the opportunity to fine-tune and optimise your existing deployments. 

For MongooseIM setups that may be encountering issues or not running as smoothly as desired, this service provides a lifeline to diagnose and rectify any problems, ensuring a more reliable and efficient operation. 

Moreover, this service is also beneficial for anyone who simply wants the peace of mind that their MongooseIM deployment is in top-notch condition, performing at its peak, and ready to handle their messaging needs with utmost efficiency. 

It is a versatile solution designed to enhance the health, efficiency, and performance of your MongooseIM deployments.

What Happens After the MongooseIM Health Check

Whether your MongooseIM installation is already optimised or if you find yourself in need of further support, rest assured that we have you covered. 

Our MongooseIM Support team is ready to assist you with any future issues or questions pertaining to your MongooseIM system. If you’ve delved into customising the MongooseIM source code or have implemented custom modules, our Code Review Consultancy can provide invaluable guidance. Ensuring the robustness of your system – especially in handling anticipated loads, is critical, and our Load Testing service is here to help – particularly if load testing has yet to be regularly conducted.

Should your plans extend beyond a standard MongooseIM deployment, we offer customisation expertise to tailor your server adjustments. Troubleshooting Consultancy is available for those perplexing issues that may not fall under known problems. For those looking to enhance their skills, we highly recommend our Administration and Operation Training, which is universally beneficial for all MongooseIM deployments. 

Furthermore, if you’re envisioning future MongooseIM development, consider exploring our MongooseIM Development Training for comprehensive insights.

Why Choose Erlang Solutions

We are the very creators of MongooseIM itself. 

You won’t find a team with a more in-depth understanding of the platform.  Our dedication to providing top-notch messaging solutions globally is unwavering, and our experienced team has successfully worked in various industries – giving us valuable insights for every project we take on.

Effective communication is central to our approach, as we prioritise keeping our clients informed and managing expectations transparently. We also offer a range of comprehensive services – including consultancy, development, code and architecture reviews, and training, to support our clients in their endeavours. 

When it comes to MongooseIM, there’s simply no better choice than us.

Is Mongoose IM Health Check Right for You?

If you want to ensure your messaging system is operating at its best, we’d love to hear from you. Reach out to us today and take the first step toward optimising your MongooseIM deployment. 

Your messaging environment will thank you for it.

The post MongooseIM Health-Check appeared first on Erlang Solutions.

by Cara May-Cole at October 18, 2023 10:01

Monal IM

Monal 6.0 released

After several month of hard work we just released Monal 6.0. This version comes with new artwork by Ann-Sophie Zwahlen, support for Audio-Calls funded by the EU’s NGI Assure via the NLnet Foundation and many other improvements and bugfixes. The full list of changes can be seen below:

NEW: Audio-call support (This feature will not be available to users in China and macOS users!)

Other changes:

  • New Logo and new placeholder images by Ann-Sophie Zwahlen
  • New “Add Contact” and “Contact Requests” UI
  • Complete rewrite of OMEMO code
  • Speed up app start
  • Add support for SASL2 (XEP-0388)
  • Implement XEP-0424: Message Retraction
  • Add support for creating invitations (button only displayed if your server supports it, see https://docs.modernxmpp.org/client/invites/)
  • Add timestamp when quoting older messages
  • Always show a “Notes to self“ chat
  • Overhaul implementation of last interaction display
  • Show scroll-down button in groupchats
  • OMEMO keys are copyable now (double tap)
  • Add OSS based crash reporting (KSCrash), reports can be voluntarily sent via mail
  • Fix logfile handling
  • Add XEP-0215 (external services) to server details ui
  • Only show contacts in contacts panel if they are in our roster
  • Implement invitations using qr codes in addition of xmpp: uris
  • Implement new image viewer compatible with iOS 17
  • Implement gif support in image viewer

Bugfixes:

  • Many bugfixes
  • Fix bookmarks2 handling
  • Fix XEP-0333 in private groups
  • Fix url preview for sites not having oc: tags
  • Set notifications to “mention only” when joining public channels
  • Show per-resource last interaction timestamp in resource list
  • Fix file uploading and sharing
  • Fix timer when recording audio messages
  • Fix muc avatar fetching

October 18, 2023 00:00