Hello! I’m Piotr from Erlang Solutions Poland and I have the pleasure of saving Christmas this year with the power of Erlang for you!

This is the second time we participate in the amazing event called the Advent of Code . Last year’s edition was solved by my colleague Aleksander and as far as I know – many of you enjoyed following his efforts. I hope you’ll like my tale of helping Santa too!

I’m going to publish my solutions in my GitHub repository . They will be accompanied by a commentary, added to this page on a daily basis. I will add solutions for each day in an individual folder, with my input file downloaded from the AoC website.

I’m also going to include a bit of microbenchmarking in every solution, with and without JIT. Firstly, to measure the overall performance of the code and secondly to see how much the efficiency improves thanks to JIT. I’m going to measure the computation time only with `timer:tc/3` call, as I consider time needed to compile a module and load the input file irrelevant. By “load” I mean: read it and split it into lines. Any further processing of individual lines is considered a computation. I will provide min, max and arithmetic average of 100 runs.

I’ll be implementing solutions as EScripts, so running them is a bit more straightforward. And frankly – I think they are underrated and sometimes I prefer them over writing BASH scripts. I’ll always include `-mode(compile).` directive to avoid the interpretation performance penalty. For those who are not aware of this capability, I’ll also run Day 1 without this option to show you how the timings change.

I’m going to run every piece of the code on Linux Mint 21.2 VirtualBox machine with 4 cores and 8GB of memory, hosted on my personal PC with Ryzen 3700X and DDR4 at 3200MHz. I will use OTP 26.1.1.

Day 1

Part 1

I would never suspect that I’ll begin the AoC challenge with being loaded onto a trebuchet. I’d better do the math properly! Or rather – have Erlang do the calibration for me.

FYI: I do have some extra motivation to repair the snow production: my kids have been singing “Do You Want to Build a Snowman?” for a couple of days already and there is still nowhere enough of it where I live.

I considered three approaches to the first part of the puzzle:

1. Run a regular expression on each line.
2. Filter characters of a line with binary comprehension and then get the first and last digit from the result.
3. Iterate over characters of a line and store digits in two accumulators.

I chose the last one, as (1) felt like shooting a mosquito with a M61 Vulcan Cannon. Second one felt kind of less Erlang-ish than the third one. After all, matching binaries and recursive solutions are very natural in this language.

Timings

Part 2

By choosing the method of matching binaries, I was able to add support for digits as words pretty easily. If there were more mappings than just nine, I’d probably use a map to store all possible conversions and maybe even compile a regular expression from them.

Eventually, the temptation of violating the DRY rule a bit was too strong and I just went for individual function clauses.

And my solution was invalid. Shame on me but I admit I needed a hint from other participants – it turned out that some words can overlap and they have to be treated as individual digits. It wasn’t explicitly specified and ignoring overlaps in the example did not lead to an invalid result – a truly evil decision of AoC maintainers!

Simply put, at first I thought such a code would be enough:

parse(<<"one", Rest/binary>>, First, _Last) -> store(1, Rest, First);

But the actual Rest must be defined as <<_:8, Rest/binary>>.

Timings

JIT does make a difference, doesn’t it?

The post Advent of Code 2023 appeared first on Erlang Solutions .

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 November 31st, 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.

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.

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

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

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

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

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

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

update_sql_schema: true

This is compatible with the following relational databases:

• MySQL
• PostgreSQL
• SQLite

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

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

Wow!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 post - 1 participant

Read full topic

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

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

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

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

We are looking for your help!

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

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

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

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

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

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

1 post - 1 participant

Read full topic

Introduction

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

Closing Remarks

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

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

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

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

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

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

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

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

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

Special Thanks

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

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