At Erlang Solutions, we’ve worked with diverse clients, solving business challenges and delivering impactful results. We would like to share just some of our top client case studies in this latest post with you.

Get a glimpse into how our leading technologies—Erlang, Elixir, MongooseIM, and more—combined with our expert team, have transformed the outcomes for major industry players.

Transforming streaming with zero downtime for TV4

Our first client case study is our partnership with TV4. The leading Nordic broadcaster needed to address major challenges in the competitive streaming industry. With global giants like Netflix and Disney Plus on the rise, TV4 needed to unify user data from multiple platforms into a seamless streaming experience for millions of subscribers.

Using Elixir, we ensured a smooth migration and helped TV4 reduce infrastructure costs and improve efficiency. 

Check out the full TV4 case study. 

Financial services with secure messaging solutions with Teleware

Erlang Solutions partnered with Teleware to enhance their Reapp with secure instant messaging (IM) capabilities for a major UK financial services group. As TeleWare aimed to meet strict regulatory requirements while improving user experience, they needed a robust, scalable solution that could seamlessly integrate into their existing infrastructure. 

We utilised MongooseIM’s out-of-the-box functionality, and Teleware quickly integrated group chat features that allowed secure collaboration while meeting the Financial Conduct Authority (FCA) compliance standards. 

Take a look at the full Teleware case study.

Gaming experiences with enhanced scalability and performance for FACEIT

FACEIT, the leading independent competitive gaming platform with over 25 million users, had some scalability and performance challenges. As its user base grew, FACEIT needed to upgrade their systems to handle hundreds of thousands of players seamlessly. 

By upgrading to the latest version of MongooseIM and Erlang, we delivered a solution that managed large user lists and improved overall system efficiency.

Explore the full FACEIT case study.

Rapid growth with scalable systems for BET Software

In another one of our client case studies, we worked with BET Software, a leading betting software provider in South Africa, to address the challenges posed by rapid growth and increasing user demand. As the main technology provider for Hollywoodbets, BET Software needed a more resilient and scalable system to support peak betting periods. 

By utilising Elixir to support and transition to a distributed data architecture, we helped BET Software eliminate bottlenecks and ensure seamless service- even during the busiest betting events. 

Read the BET Software case study in full.

Innovation and competitive edge with International Registries Inc.

The final client case study of this series is with International Registries Inc. (IRI). They are global leaders in maritime and corporate registry services, who were looking to enhance its technological infrastructure and strengthen their competitive advantage.

Erlang Solutions helped IRI by using Elixir to reduce costs, improve system maintainability, and decommission servers. 

Discover the complete IRI case study. 

Real results from client case studies 

Our client case study examples show how we help companies like TV4, FACEIT, TeleWare, BET Software, and International Registries Inc. solve tough tech challenges and excel in competitive markets. Whether it’s boosting performance, securing communications, or scaling for growth, our solutions unlock new possibilities.

You can explore more Erlang Solutions case studies here.

If you’d like to chat with the Erlang Solutions team about what we can do for you, feel free to drop us a message.

The post Client Case Studies with Erlang Solutions appeared first on Erlang Solutions.

The Ignite Realtime developer community is happy to announce that Smack 4.5 entered its beta phase. Smack is a XMPP client API written in Java that is able to run on Java SE and Android. Smack’s beta phase started already a few weeks ago, but 4.5.0-beta5 is considered to be a good candidate to announce, as many smaller issues have been ironed out.

With Smack 4.5 we bumped the minimum Java version to 11. Furthermore Smack now requires a minimum Android API of 26 to run.

If you are using Smack 4.4 (or maybe an even older version), then right now is the perfect time to create an experimental branch with Smack 4.5 to ease the transition.

Smack 4.5 APIs is considered stable, however small adjustments are still possible during the beta phase.

1 post - 1 participant

Read full topic

Every year in October I participate in Love To Ride’s (psst, sign up using that link so I can get some extra points when you do your first bike ride!) Biketober competition. The TL;DR is that for every day that you go for a ride, for every mile that you ride, and for every new rider that you invite you get points for your team. At the end of the month winners are announced and there are some fun prizes. It’s not about big miles, it’s about getting more people outside riding bikes, and I love it for that.

This year in addition to Biketober I’ve decided to try the, unrelated, annual Coffeeneuring Challenge. If you’re not familiar with the challenge, the idea is pretty simple: between October 6th and November 18th you ride your bike to 7 different coffee (or other approved beverage) locations, with some minor limits on distance and how often a coffee place qualifies. For a full list of “rules” you can see this years post: “Coffeeneuring Challenge 2024: The Year of Small Wins”.

We’re a little ways into the challenge already, so this post will be how I document my rides for this year going forward! Let’s start with a few I’ve already done. For the purpose of the rules I’ll be starting my weeks on Monday, because that’s just how weeks work and this ridiculous notion that Sunday is both the “weekend” but also somehow the start of the week needs to be abolished.

Week One (Oct 05–06)

Oct 5th

Per rule 2: “Soft Launch Saturday” I completed my first ride of the joint Biketober/Coffeeneuring season! I was on my way back from an IWW meeting at the Little Five Points Community Center and decided that I’d make a detour to stop at Taco Cantina for a Horchata de arroz. Per rule 6 (“Controversial Beverage Rule”) this was adjudicated in the Court of Coffeneuring Public Opinion on fedi and now only awaits a final ruling by the Coffeneuring Challenge Committee and the Intern.

The overall ride was rather uneventful, but also highlights the major mobility gap in Cobb County, GA. The first four or so miles are from my house to the Cumberland Transfer Center which is the only place in the county that you can catch a rapid bus into Atlanta. I’m lucky enough to be close to the bus station, otherwise I would have to catch another bus to get there which, on the weekend, runs about once an hour. Not an ideal situation: trying to catch a transfer involving two buses that both run once an hour. If you bike, as I did, you can follow the Spring Road Trail and the Mountain to River Trail (M2R) all the way to the transfer center. While this is great in theory because it gets you off the 4 lane road where people regularly do 60mph, the road that the trail is next to is really more of a stroad so every retail establishment along the road has cars pulling out or in who aren’t looking for cyclists and it can be a rather harrowing ride.

Once you catch the bus and arrive at Arts Center Station the transit system improves a tiny bit. Transferring to the train is free and requires one transfer to the blue line which will take you to Inman Park/Reynoldstown Station. As I left the station I was surprised to find a small cycle path that I didn’t know about, Poplar Court Northeast, that cuts through the park to Euclid Ave right next to the Community Center!

The total distance round trip came out to 8.18 miles. A partial GPX trace for this ride can be found here.

Oct 6th

The next day I went out for a group ride. To get a few extra miles in this Biketober I decided to ride to Knight Park where the group was meeting at instead of taking the bus. The total distance to the park was 10.26 miles, mostly along Atlanta Road. This may have been one of the stupider cycling decisions I’ve made in a while; in theory there is a bike path being built alongside the road, but there are major gaps with no plans to fill them in as well and no good way to get off the road at points, especially when crossing bridges.

The group ride itself ended up being 10.36 miles, only 0.1 more than the commute, but was a much more enjoyable ride through Westside Park, Atlanta’s largest public park. At the end we stopped off at The Whelan for a bite and a drink! I went with a local Märzen; it’s not a coffee, but Oktoberfest beers seems like good Coffeeneuring drinks to me (though it did not come in the traditional Maß, which is always disappointing). During the winter proper this pub also serves mulled wine, so maybe I’ll stop back by for one of my last rides if they start serving it in time.

The total ride distance (after checking out an open streets festival and a partial ride home) came out to 24.35 miles. A partial GPX trace for this ride can be found here.

Week Two (Oct 07–13)

Oct 10th

I rode down to meet a friend at Viking Alchemist Meadery, an easy few miles along the M2R trail I mentioned before. I’d never had mead before so the bartender kindly let me try a few samples before deciding what I wanted. It’s not my favorite drink, but a few of the more sour ones were quite nice and a 4 year aged one that I can’t afford (but which he let me take a small sip of) was very nice and it felt like a good Coffeeneuring style drink to me!

I arrived a bit early and they weren’t open yet, so I explored a bit and ended up with a total ride of 5.72 miles. The GPX trace can be found here.

Oct 12th

A few days later the nearby city of Marietta, GA was having their annual Chalktoberfest celebration, two days of street art, beers, and a square that’s actually usable by people, not just cars! I took a ride up the M2R trail in the other direction this time to hand out some fliers encouraging people to vote for the Cobb County Mobility SPLOST which will fund a mix of Bus Rapid Transit (BRT) lines and bicycle path improvements in Cobb. On the way back I stopped at Pie Bar and had my first cup of actual coffee! The city of Smyrna was also having its birthday celebration on the same day so I ended up also going back and forth between home and the Smyrna downtown area several times to hear the various concerts. This year featured “Letters to Cleo” and “The Roots” as well as a number of local bands!

Overall ride length ended up being 18.66 miles and a GPX of the main M2R portion can be found here.

Week 3 (Oct 14-20)

Oct 15th

It’s October 15th and that means it’s the first day of early voting in Georgia! I took a ride over to the Smyrna Community Center to see what the line was like and was pleased to see that a lot more people than I’ve ever seen during early voting were already queued up (~1 hour wait time according to one of the poll workers).

Nextdoor to the Community Center is the library, so I stopped by there as well and on a whim picked up a copy of “Everyday Utopia” by Kristen R. Ghodsee and “The Contradictions” by Sophie Yanow. I’ve never heard of Yanow, but the book had a bicycle on the cover so that seemed like a good enough reason to grab it. I’ve had Ghodsee’s “Why Women Have Better Sex Under Socialism: And Other Arguments for Economic Independence” on my “To Read” list for a while, and wasn’t aware that my library had any of her books, so I was excited to learn about “Everyday Utopia”.

Right up the street is Café Lucia so I also stopped for a coffee to complete today’s Coffeeneuring outing. I was pleased to see that they had several fliers with information about the MSPLOST tax on the ballot on their bulletin board that were put out by someone else; sometimes it’s easy to think you’re the only person who cares about public transit, so it’s nice to remember that other people are out there fighting for this as well.

The total ride came out to 3.24 miles, and a GPX is available here.

Oct 16th

My ride today involved several errands on the way to the coffee shop. I first stopped by an auto parts store to drop off some used engine oil from my motorcycle, then biked over to the library to return “The Contradictions” (it was much shorter than I realized and was fun, despite comics not really being my thing).

The line looked shorter at the community center (15 minutes as opposed to the hour it would have taken yesterday) so I went in to cast my vote; the big ticket items for me were Harris for president, of course, but also the previously mentioned MSPLOST and a local Democratic Socialist running in GA HD 42. This is all more-or-less on the way to Rev Coffee where I stopped off to use the wifi and get a little work done. As always, the coffee was excellent, but the bike parking was inadequate and cramped.

Traditionally, the fintech industry relied on proprietary software, with usage and distribution restricted by paid licences. Fintech open-source technologies were distrusted due to security concerns over visible code in complex systems.

But fast-forward to today and financial institutions, including neobanks like Revolut and Monzo, have embraced open source solutions. These banks have built technology stacks on open-source platforms, using new software and innovation to strengthen their competitive edge.

While proprietary software has its role, it faces challenges exemplified by Oracle/Java’s subscription model changes, which have led to significant cost hikes. In contrast, open source Delivers flexibility, scalability, and more control, making it a great choice for fintechs aiming to remain adaptable.

Curious why open source is the smart choice for fintech? Let’s look into how this shift can help future-proof operations, drive innovation, and enhance customer-centric services.

The impact of Oracle Java’s pricing changes

Before we understand why open source is a smart choice for fintech, let’s look at a recent example that highlights the risks of relying on proprietary software—Oracle Java’s subscription model changes.

A change to subscription

Java, known as the “language of business,” has been the top choice for developers and 90% of Fortune 500 companies for over 28 years, due to its stability, performance, and strong Oracle Java community.

In January 2023, Oracle quietly shifted its Java SE subscription model to an employee-based system, charging businesses based on total headcount, not just the number of users. This change alarmed many subscribers and resulted in steep increases in licensing fees. According to Gartner, these changes made operations two to five times more expensive for most organisations.

Oracle Java SE Universal Subscription Global Price List (by volume)

Impact on Oracle Java SE user base

By January 2024, many Oracle Java SE subscribers had switched to OpenJDK, the open-source version of Java. Online sentiment towards Oracle has been unfavourable, with many users expressing dissatisfaction in forums. Those who stuck with Oracle are now facing hefty subscription fee increases with little added benefit.

Lessons from Oracle Java SE

For fintech companies, Oracle Java’s pricing changes have highlighted the risks of proprietary software. In particular, there are unexpected cost hikes, less flexibility, and disruptions to critical infrastructure. Open source solutions, on the other hand, give fintech firms more control, reduce vendor lock-in, and allow them to adapt to future changes while keeping costs in check.

The advantages of open source technologies for Fintech

Open source software is gaining attention in financial institutions, thanks to the rise of digital financial services and fintech advancements. 

It is expected to grow by 24% by 2025 and companies that embrace open-source benefit from enhanced security, support for cryptocurrency trading, and a boost to fintech innovation. 

Cost-effectiveness

The cost advantages of open-source software have been a major draw for companies looking to shift from proprietary systems. For fintech companies, open-source reduces operational expenses compared to the unpredictable, high costs of proprietary solutions like Oracle Java SE.

Open source software is often free, allowing fintech startups and established firms to lower development costs and redirect funds to key areas such as compliance, security, and user experience. It also avoids fees like:

• Multi-user licences
• Administrative charges
• Ongoing annual software support charges

These savings help reduce operating expenses while enabling investment in valuable services like user training, ongoing support, and customised development, driving growth and efficiency.

A solution to big tech monopolies

Monopolies in tech, particularly in fintech, are increasing. As reported by CB Insights, about 80% of global payment transactions are controlled by just a few major players. These monopolies stifle innovation and drive up costs.

Open-source software decentralises development, preventing any single entity from holding total control. It offers fintech companies an alternative to proprietary systems, reducing reliance on monopolistic players and fostering healthy competition. Open-source models promote transparency, innovation, and lower costs, helping create more inclusive and competitive systems.

Transparent and secure solutions

Security concerns have been a major roadblock that causes companies and startups to hesitate in adopting open-source software.

A common myth about open source is that its public code makes it insecure. But, open-source benefits from transparency, as it allows for continuous public scrutiny. Security flaws are discovered and addressed quickly by the community, unlike proprietary software, where vulnerabilities may remain hidden.

An example is Vocalink, which powers real-time global payment systems. Vocalink uses Erlang, an open-source language designed for high-availability systems, ensuring secure, scalable payment handling. The transparency of open source allows businesses to audit security, ensure compliance, and quickly implement fixes, leading to more secure fintech infrastructure.

Ongoing community support

Beyond security, open source benefits from vibrant communities of developers and users who share knowledge and collaborate to enhance software. This fosters innovation and accelerates development, allowing for faster adaptation to trends or market demands.

Since the code is open, fintech firms can build custom solutions, which can be contributed back to the community for others to use. The rapid pace of innovation within these communities helps keep the software relevant and adaptable.

Interoperability

Interoperability is a game-changer for open-source solutions in financial institutions, allowing for the seamless integration of diverse applications and systems- essential for financial services with complex tech stacks. 

By adopting open standards (publicly accessible guidelines ensuring compatibility), financial institutions can eliminate costly manual integrations and enable plug-and-play functionality. This enhances agility, allowing institutions to adopt the best applications without being tied to a single vendor.

A notable example is NatWest’s Backplane, an open-source interoperability solution built on FDC3 standards. Backplane enables customers and fintechs to integrate their desktop apps with various banking and fintech applications, enhancing the financial desktop experience. This approach fosters innovation, saves time and resources, and creates a more flexible, customer-centric ecosystem.

Future-proofing for longevity

Open-source software has long-term viability. Since the source code is accessible, even if the original team disbands, other organisations, developers or the community at large can maintain and update the software. This ensures the software remains usable and up-to-date, preventing reliance on unsupported tools.

Open Source powering Fintech trends

According to the latest study by McKinsey and Company, Artificial Intelligence (AI), machine learning (ML), blockchain technology, and hyper-personalisation will be among some of the key technologies driving financial services in the next decade. 

Open-source platforms will play a key role in supporting and accelerating these developments, making them more accessible and innovative.

AI and fintech innovation

• Cost-effective AI/ML: Open-source AI frameworks like TensorFlow, PyTorch, and Scikit-learn enable startups to prototype and deploy AI models affordably, with the flexibility to scale as they grow. This democratisation of AI allows smaller players to compete with larger firms.
• Fraud detection and personalisation: AI-powered fraud detection and personalised services are central to fintech innovation. Open-source AI libraries help companies like Stripe and PayPal detect fraudulent transactions by analysing patterns, while AI enables dynamic pricing and custom loan offers based on user behaviour.
• Efficient operations: AI streamlines back-office tasks through automation, knowledge graphs, and natural language processing (NLP), improving fraud detection and overall operational efficiency.
• Privacy-aware AI: Emerging technologies like federated learning and encryption tools help keep sensitive data secure, for rapid AI innovation while ensuring privacy and compliance.

Blockchain and fintech 

Open-source blockchain platforms allow fintech startups to innovate without the hefty cost of proprietary systems:

• Open-source blockchain platforms: Platforms like Ethereum, Bitcoin Core, and Hyperledger are decentralising finance, providing transparency, reducing reliance on intermediaries, and reshaping financial services.
• Decentralised finance (DeFi):  DeFi is projected to see an impressive rise, with P2P lending growing from $43.16 billion in 2018 to an estimated $567.3 billion by 2026. Platforms like Uniswap and Aave, built on Ethereum, are pioneering decentralised lending and asset management, offering an alternative to traditional banking. By 2023, Ethereum alone locked $23 billion in DeFi assets, proving its growing influence in the fintech space. Enterprise blockchain solutions: Open source frameworks like Hyperledger Fabric and Corda are enabling enterprises to develop private, permissioned blockchain solutions, enhancing security and scalability across industries, including finance.

Cost-effective innovation: Startups leveraging open-source blockchain technologies can build innovative financial services while keeping costs low, helping them compete effectively with traditional financial institutions.

Hyper-personalisation

Hyper-personalisation is another key trend in fintech, with AI and open-source technologies enabling companies to create highly tailored financial products. This shift moves away from the traditional “one-size-fits-all” model, helping fintechs solve niche customer challenges and deliver more precise services.

Consumer demand for personalisation

A Salesforce survey found that 65% of consumers expect businesses to personalise their services, while 86% are willing to share data to receive more customised experiences.

source- State of the connected customer

The expectation for personalised services is shaping how financial institutions approach customer engagement and product development.

Real-world examples of open-source fintech

Companies like Robinhood and Chime leverage open-source tools to analyse user data and create personalised financial recommendations. These platforms use technologies like Apache Kafka and Apache Spark to process real-time data, improving the accuracy and relevance of their personalised offerings-from customised investment options to tailored loan products.

Implementing hyper-personalisation lets fintech companies strengthen customer relationships, boost retention, and increase deposits. By leveraging real-time, data-driven technologies, they can offer highly relevant products that foster customer loyalty and maximise value throughout the customer lifecycle. With the scalability and flexibility of open-source solutions, companies can provide precise, cost-effective personalised services, positioning themselves for success in a competitive market.

Erlang and Elixir: Open Source solutions for fintech applications

Released as open-source in 1998, Erlang has become essential for fintech companies that need scalable, high-concurrency, and fault-tolerant systems. Its open-source nature, combined with the capabilities of Elixir (which builds on Erlang’s robust architecture), enables fintech firms to innovate without relying on proprietary software, providing the flexibility to develop custom and efficient solutions.

Both Erlang and Elixir’s architecture are designed to ensure potentially zero downtime, making them well-suited for real-time financial transactions.

Why Erlang and Elixir are ideal for Fintech:

• Reliability: Erlang’s and Elixir’s design ensures that applications continue to function smoothly even during hardware or network failures, crucial for financial services that operate 24/7, guaranteeing uninterrupted service. Elixir inherits Erlang’s reliability while providing a more modern syntax for development.
• Scalability: Erlang and Elixir can handle thousands of concurrent processes, making them perfect for fintech companies looking to scale quickly, especially when dealing with growing data volumes and transactions. Elixir enhances Erlang’s scalability with modern tooling and enhanced performance for certain types of workloads.
• Fault tolerance: Built-in error detection and recovery features ensure that unexpected failures are managed with minimal disruption. This is vital for fintech applications, where downtime can lead to significant financial losses. Erlang’s auto restoration philosophy and Elixir’s features enable 100% availability and no transaction is lost.
• Concurrency & distribution: Both Erlang and Elixir excel at managing multiple concurrent processes across distributed systems. This makes them ideal for fintechs with global operations that require real-time data processing across various locations.

Open-source fintech use cases

Several leading fintech companies have already used Erlang to build scalable, reliable systems that support their complex operations and real-time transactions.

• Klarna: This major European fintech relies on Erlang to manage real-time e-commerce payment solutions, where scalability and reliability are critical for managing millions of transactions daily.
• Goldman Sachs: Erlang is utilised in Goldman Sachs’ high-frequency trading platform, allowing for ultra-low latency and real-time processing essential for responding to market conditions in microseconds.
• Kivra: Erlang/ Elixir supports Kivra’s backend services, managing secure digital communications for millions of users, and ensuring constant uptime and data security.

Erlang and Elixir -supporting future fintech trends

The features of Erlang and Elixir align well with emerging fintech trends:

• DeFi and Decentralised Applications (dApps): With the growth of decentralised finance (DeFi), Erlang’s and Elixir’s fault tolerance and real-time scalability make them ideal for building dApps that require secure, distributed networks capable of handling large transaction volumes without failure.
• Hyperpersonalisation: As demand for hyperpersonalised financial services grows, Erlang and Elixir’s ability to process vast amounts of real-time data across users simultaneously makes them vital for delivering tailored, data-driven experiences.
• Open banking: Erlang and Elixir’s concurrency support enables fintechs to build seamless, scalable platforms in the open banking era, where various financial systems must interact across multiple applications and services to provide integrated solutions.

Erlang and Elixir can handle thousands of real-time transactions with zero downtime making them well-suited for trends like DeFi, hyperpersonalisation, and open banking. Their flexibility and active developer community ensure that fintechs can innovate without being locked into costly proprietary software.

To conclude

Fintech businesses are navigating an increasingly complex and competitive landscape where traditional solutions no longer provide a competitive edge. If you’re a company still reliant on proprietary software, ask yourself: Is your system equipped to expect the unexpected? Can your existing solutions keep up with market demands? 

Open-source technologies offer a solution to these challenges. Fintech firms can reduce costs, improve security, and, most importantly, innovate and scale according to their needs. Whether by reducing vendor lock-ins, tapping into a vibrant developer community, or leveraging customisation, open-source software is set to transform the fintech experience, providing the tools necessary to stay ahead in a digital-first world. If you’re interested in exploring how open-source solutions like Erlang or Elixir can help future-proof your fintech systems, contact the Erlang Solutions team.

The post Why Open Source Technology is a Smart Choice for Fintech Businesses appeared first on Erlang Solutions.

A new boost in the project’s budget will allow us to approximately double the test coverage of our project (and add a couple of nice features)!

Much of the XMPP Interop Testing project was made possible as the work was funded through the NGI0 Core Fund. This is a fund established by NLnet with financial support from the European Commission’s Next Generation Internet programme.

It is quite remarkable how far the effects of funding reach: it allowed us to work out our plans to take various, pre-existing bits and bobs, and quickly and efficiently turn a small tool used for internal testing to a proper testing framework for any XMPP server implementation to be able to use. That snowballed in bug fixes for server implementations, and improvements to specifications used by many. A relatively small fund thus improved the quality of open standard-based communication used in one shape or another by countless people, daily!

We are so happy and grateful to NLnet for boosting our project’s grant! With the additional work, we will add the following improvements:

• Have better test coverage by writing more tests;
• Improve feedback when tests fail or do not run at all;
• Add a new test account provisioning option;
• Improve test selection configuration;
• Automate recurring maintenance tasks;
• Add support for other build systems.

This all will help us improve our framework, it will help our users to improve their products, and will allow new projects to more easily deploy our open and free solutions into their CI pipelines!

You can expect a lot of these improvements to become available to you, soon!

• Splash image courtesy of Micheile Henderson, Unsplash

We’re excited to announce the latest enhancement to Fluux.io services – the integration of WebPush support. This significant update extends our services beyond
FCM/APNs, enabling push notifications for XMPP across various platforms. Now, our push notification capabilities are not limited to native mobile clients on iOS, MacOS and Android, but also extend to web applications on browsers like Safari, Chrome, Firefox and more. This includes support for mobile versions of Safari and Chrome. This advancement broadens the scope for XMPP clients, offering new possibilities and a more extensive reach. Please also note that the Webpush support is also available to our customers using our on-premise ejabberd Business Edition.

To enable it, go to your services in your fluux.io console, select “Push Notifications” and then “+ WebPush”

You will be prompted for an appid (typically the domain you want to enable WebPush on). For example here fluux.io. It will generate a VAPID key that will be used by ejabberd to sign the push notification sent to the user’s browser.

Checking “View Config” will allow you to see the VAPID public key. It will be required to let the browser subscribe to notifications. Your website also needs to register a service worker that will be responsible for displaying the notification when a push is received.

As an example, we provide a small ejabberd client to test the whole workflow. It is pre-populated with a test user and associated appid/key.

The first step is to authenticate an XMPP user through your service. Then click “Enable Push“.

It will ask authorization to enable push notification and create a subscription to FCM/Apple/Mozilla services. Then the XMPP client (using strophe.js) will send a stanza to enable offline messaging. ejabberd will now send a notification to this entry point, which will send a push to the user’s browser.

To trigger it, disconnect/close all opened XMPP sessions of your test user and send him a message from another test user. Your browser will display a notification from your website with the message snippet and its author. You can then check triggered notification on your Push logs console

Alternatively, you can check the test user and its associated devices:

and send a test notification:

The post WebPush support on your fluux.io instance first appeared on ProcessOne.

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of September 2024.

XSF Announcements

If you are interested in joining the XMPP Standards Foundation as a member, please apply until November 24th, 2024!.

The XMPP Standards Foundation is also calling for XSF Board 2024 and XSF Council 2024. Be involved in the XMPP Standards Foundation organisation decisions as well as on our specifications we publish. If you are interested in running for Board or Council, please add a wiki page about your candidacy to one or both of the following sections until November 3rd, 2024, 00:00 UTC. Note: XMPP Council members must be elected members of the XSF; however, there is no such restriction for the Board of Directors.

XMPP and Google Summer of Code 2024

The XSF has been accepted as a hosting organisation at GSoC in 2024 again! These XMPP projects have received a slot and have kicked-off with coding:

• Monal
  • Modern Monal onboarding and Media gallery (175 hours, medium)
    • Blog post 1
    • Blog post 2

XSF and Google Summer of Code 2024

XSF Fiscal Hosting Projects

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

• Mellium Co-op
• Bifrost bridge
• Prav iOS
• diasp.in

XMPP Events

• Berlin XMPP Meetup (DE / EN): monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month at 6pm local time
• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming).

Videos

• Detailed and comprehensive introduction to Rivista XJP: the XMPP PubSub Content Management System.

XMPP Articles

• XMPP Interop Testing: Containers
• List of projects that got worked on in September’s XMPP Sprint in Worcester, UK!.
• Monal Internals - XML Query Language: This new article shines some light onto specific parts of Monal’s internals. It is dedicated to programmers or people curious about how Monal works internally.
• The Quick and Easy Guide to Jabber/XMPP: Why XMPP matters.
• Straight from The Dandelion Hub: Installation of an XMPP-based messenger using Movim as frontend and Prosody as backend on Linux Debian 12 – A tutorial.

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.15.3-4 for Android.
• Conversations has released version 2.16.7 for Android.
• Psi+ 1.5.2041 installer has been released.
• Gajim 1.9.4 and 1.9.5 have been released. These releases come with integrated support for the XMPP Providers project. Furthermore, there is now support for “Hats” (XEP-0317), which allow you to assign roles to group chat participants, i.e. “Support”, “Expert” or really anything you like to assign. Last but not least, Gajim’s Microsoft Store release has been improved in many ways. You can check the changelog for more details.
• Movim 0.28 has been released. This new version (code named “Tempel”) brings a “Freshly redesigned Search panel, improved account gateways and administration features, databases fixes and a new call flow and conference lobby” among many other fixes and improvements.

Movim 0.28 (Tempel) Introducing the new call flow and conference lobby

XMPP Servers

• Snikket is pleased to announce a new stable release of the Snikket server stable.20240904 software. For an introduction to the new changes, check out the release announcement blog post.
• Openfire 4.9.0 release! The Ignite Realtime community is happy to announce the immediate availability of version 4.9.0 of Openfire, its cross-platform real-time collaboration server based on the XMPP protocol! You can read the full changelog for more details.

XMPP Libraries & Tools

Ignite Realtime community:

• Hazelcast plugin for Openfire version 3.0.0 has been released, adding clustering support to Openfire. It is based on the Hazelcast platform. This release brings a major upgrade of the platform. It migrates from version 3.12.5 to 5.3.7. Please read the upgrade instructions carefully for this one.
• HTTP File Upload plugin for Openfire version 1.4.1 has been released. This plugin adds functionality to Openfire that allows clients to share files, as defined in XEP-0363: HTTP File Upload.
• nbxmpp 5.0.4 comes with a fix for MUC passwords and further bug fixes.
• go-sendxmpp 0.11.2 has been released.

Extensions and specifications

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

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

Proposed

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

• Happy Eyeballs

New

• Version 0.1.0 of XEP-0493 (OAuth Client Login)
  • Promoted to Experimental (XEP Editor: dg)
• Version 0.1.0 of XEP-0494 (Client Access Management)
  • Promoted to Experimental (XEP Editor: dg)

Deferred

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

• No XEPs deferred this month.

Updated

• Version 2.13.2 of XEP-0004 (Data Forms)
  • Add section on empty and absent values. (gk)
• Version 1.35.1 of XEP-0045 (Multi-User Chat)
  • Add explicit error definition when non-owners attempt to use owner-specific functionality. (gk)
• Version 1.3.1 of XEP-0133 (Service Administration)
  • Fixed typo in example for Get User Last Login Time (dc)
• Version 0.4.2 of XEP-0264 (Jingle Content Thumbnails)
  • Restrict ‘width’ and ‘height’ to the 0..65535 range, instead of being unbounded integers. This is in accordance to XEP-0084 and XEP-0221 for instance. (egp)
• Version 0.2.0 of XEP-0272 (Multiparty Jingle (Muji))
  • Send Jingle IQs to real JID
  • Define how to use with XEP-0482
  • Adjust namespace (lmw)
• Version 1.1.2 of XEP-0313 (Message Archive Management)
  • Fix JID and affiliation of the first two witches in the MUC example.
  • Fix duplicated ‘id’ in MUC example.
  • Fix indentation in examples. (egp)
• Version 0.3.1 of XEP-0474 (SASL SCRAM Downgrade Protection)
  • Fix typos
  • Adapt attack-model section to new simplified protocol (tm)

Last Call

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

• No Last Call this month.

Stable

• No XEP moved to Stable this month.

Deprecated

• No XEP deprecated this month.

Rejected

• No XEP rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• Twitter
• YouTube
• LinkedIn
• Lemmy instance (unofficial)
• Reddit (unofficial)
• XMPP Facebook page (unofficial)

Also check out our RSS Feed!

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

Newsletter Contributors & Translations

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

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• Italian: notes.nicfab.eu
  • Translators: nicola
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi
• German: xmpp.org
  • Translators: Millesimus

Help us to build the newsletter

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

Tasks we do on a regular basis:

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

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

If you’re an Elixir, Gleam, or Erlang developer, you’ve probably heard about the capabilities of the BEAM virtual machine, such as concurrency, distribution, and fault tolerance. Fault tolerance was one of the biggest concerns of Tandem Computers. They created their Tandem Non-Stop architecture for high availability in their systems, which included ATMs and mainframes.

In this post, I’ll be sharing the fundamentals of the NonStop architecture design with you. Their approach to achieving high availability in the presence of failures is similar to some implementations in the Erlang Virtual Machine, as both rely on concepts of processes and modularity.

Systems with High Availability

Why do systems fail? This question should probably be asked more often, considering all the factors it involves. It was central to the NonStop architecture because achieving high availability depends on understanding system failures. 

For tandem systems, any system has critical components that could potentially cause failures. How often do you ask yourself how long can your system operate before a failure? There is a metric known as MTBF (mean time between failures), which is calculated by dividing the total operating hours of the system by the number of failures. The result represents the hours of uninterrupted operation.

Many factors can affect the MTBF, including administration, configuration, maintenance, power outages, hardware failures, and more. So, how can you survive these eventualities to achieve at least virtual high availability in your systems?

High availability in hardware has taught us important insights about continuous operation. Some hardware implementations rely on decomposing the system into modules, allowing for modularity to contain failures and maintain operation through backup modules instead of breaking the whole system and needing to restart it. The main concept, from this point of view, is to use modules as units of failure and replacement.

High Availability for Software Systems

But what about the software’s high availability? Just as with hardware, we can find important lessons from operative system designers who decompose systems into modules as units of service. This approach provides a mechanism for having a unit of protection and fault containment. 

To achieve fault tolerance in software, it’s important to address similar insights from the NonStop design:

• Modularity through processes and messages.
• Fault containment.
• Process pairs for fault tolerance.
• Data integrity.

Can you recognise some similarities so far?

The NonStop architecture essentially relies on these concepts. The key to high availability, as I mentioned before, is modularity as a unit of service failure and protection.

A process should have a fail-fast mechanism, meaning it should be able to detect a failure during its operation, send a failure signal and then stop its operation. In this way, a system can achieve fault detection through fault containment and by sharing no state. 

Another important consideration for your system is how long it takes to recover from a failure. Jim Gray, software designer and researcher at Tandem Computers, in his paper ”Why computers stop and what can be done about it?” proposed a model of failure affected by two kinds of bugs: Bohrbugs, which cause critical failures during operation, and Heisenbugs, which are more soft and can persist in the system for years. 

Implementing Processes-Pairs Strategies

The previous categorisation helps us to understand better strategies for implementing processes-pairs design, based on a primary process and a backup process:

• Lockstep: Primary and backup processes execute the same task, so if the primary fails, the backup continues the execution. This is good for hardware failures, but in the presence of Heisenbugs, both processes will remain the failure. 
• State checkpointing: A requestor entity is connected to a processes-pair. When the primary process stops operation, the requestor switches to the backup process. You need to design the requestor logic. 
• Automatic checkpointing: Similar to the previous, but using the kernel to manage the checkpointing.
• Delta checkpointing: Similar to state checkpointing but using logical rather than physical updates.
• Persistence: When the primary process fails, the backup process starts its operation without a state. The system must implement a way to synchronise all the modules and avoid corrupt interaction.

All of these insights are drawn from Jim Gray’s paper, written in 1985 and referenced in Joe Armstrong’s 2003 thesis, “Making Reliable Distributed Systems in the presence of software errors”. Joe emphasised the importance of the Tandem NonStop system design as an inspiration for the OTP design principles. 

Elixir and High Availability

So if you’re a software developer learning Elixir, you’ll probably be amazed by all the capabilities and great tooling available to build software systems. By leveraging frameworks like Phoenix and toolkits such as Ecto, you can build full-stack systems in Elixir. However, to fully harness the power of the Erlang virtual machine (BEAM) you must understand processes. 

Just as the Tandem computer system relied on transactions, fault containment and a fail-fast mechanism, Erlang achieves high availability through processes. Both systems consider it important to modularise systems into units of service and failure: processes. 

About the process

A process is the basic unit of abstraction in Erlang, a crucial concept because the Erlang virtual machine (BEAM) operates around this. Elixir and Gleam share the same virtual machine, which is why this concept is important for the entire ecosystem. 

A process is:

• A strongly isolated entity.
• Creation and destruction is a lightweight operation.
• Message passing is the only way to interact with processes.
• Share no state.
• Do what they are supposed to do or fail.

Just remember, these are the fundamentals of Erlang, which is considered a message-oriented language, and its virtual machine (BEAM), on which Elixir runs.  

If you want to read more about processes in Elixir I recommend reading this article I wrote: Understanding Processes for Elixir Developers.

I consider it important to read papers like Jim Gray’s article because they teach us the history behind implementations that attempt to solve problems. I find it interesting to read and share these insights with the community because it’s crucial to understand the context behind the tools we use. Recognising that implementations exist for a reason and have stories behind them is essential.

 You can find many similarities between Tandem and Erlang design principles:

•  Both aim to achieve high availability.
•  Isolation of operations is extremely important to contain failure.
•  Processes that share no state are crucial for building modular systems.
•  Process interactions are key to maintaining operation in the presence of errors. While Tandem computers implemented process-pairs design, Erlang implemented OTP patterns.

To conclude

Take some time to read about the Tandem computer design. It’s interesting because these features share significant similarities with OTP design principles for achieving high availability. Failure is something we need to deal with in any kind of system, and it’s important to be aware of the reasons and know what you can do to manage it and continue your operation. This is crucial for any software developer, but if you’re an Elixir developer, you’ll probably dive deeper into how processes work and how to start designing components with them and OTP.

Thanks for reading about the Tandem NonStop system. If you like this kind of content, I’d appreciate it if you shared it with your community or teammates. You can visit this public repository on GitHub where I’m adding my graphic recordings and insights related to the Erlang ecosystem or contact the Erlang Solutions team to chat more about Erlang and Elixir.

Illustrations by Visual Partner-Ship @visual_partner 

Jaguares, ESL Americas Office 

@carlogilmar

The post Why do systems fail? Tandem NonStop system and fault tolerance appeared first on Erlang Solutions.

Introduction to XMPP

XMPP, the Extensible Messaging and Presence Protocol, is an Instant Messaging (IM) standard of the Internet Engineering Task Force (IETF) - the same organization that standardized Email (POP/IMAP/SMTP) and the World Wide Web (HTTP) protocols. XMPP evolved out of the early XML streaming technology developed by the XMPP Open Source community and is now the leading protocol for exchanging real-time structured data. XMPP can be used to stream virtually any XML data between individuals or applications, making it a perfect choice for applications such as IM.

A Brief History

IM has a long history, existing in various forms on computers as soon as they were attached to networks. Most IM systems were designed in isolation using closed networks and/or proprietary protocols, meaning each system can only exchange messages with users on the same IM network. Users on different IM networks often can’t send or receive messages, or do so with drastically reduced features because the messages must be transported through “gateways” that use a least common denominator approach to message translation.

The problem of isolated, proprietary networks in IM systems today is similar to email systems in the early days of computer networks. Fortunately for email, the IETF created early standards defining the protocols and data formats that should be used to exchange email. Email software vendors rapidly switched to the IETF standards to provide universal exchange of email among all email users on the Internet.

In 2004 the IETF published RFC 3920 and 3921 (the “Core” and “Instant Messaging and Presence” specifications for instant messaging) officially adding XMPP, mostly known as Jabber at the time, to the list of Internet standards. A year later, Google introduced Google Talk, a service that uses XMPP as its underlying protocol.

Google’s endorsement of the XMPP protocol greatly increased the visibility and popularity of XMPP and helped pave the way for XMPP to become the Internet IM standard. Over the years, more and more XMPP-based solutions followed: from Whatsapp, Jitsi, Zoom and Grinder in the IM-sphere, Google Cloud Print, Firebase Cloud Messaging and Logitec’s Harmony Hub in the IoT-realm, to Nintendo Switch, Fortnite and League of Legends in the world of gaming.

XMPP: Open, Extensible, XML Instant Messaging

The XMPP protocol benefits from three primary features that appeal to administrators, end users and developers: an IETF open standard, XML data format, and simple extensions to the core protocol. These benefits combine to position XMPP as the most compelling IM protocol available for businesses, consumers, and organizations of any size.

Open Standard Benefits

The fact that XMPP is an open standard has led to its adoption by numerous software projects that cover a broad range of environments and users. This has helped improve the overall design of the protocol, as well as ensured a “best of breed” market of client applications and libraries that work with all XMPP servers. The vibrant XMPP software marketplace contains 90+ compatible clients that operate on all standard desktop systems and mobile devices, from mobile phones to tablets.

Wide adoption has provided real-world proof that XMPP-based software from different vendors, deployed by both large and small organizations, can work together seamlessly. For example, XMPP users logged into their personal home server and an employee logged into a corporate IM server can chat, see each other’s presence on their contact lists, and participate in chat rooms hosted on an Openfire XMPP server running at a university.

XML Data

XML is one of the most popular, robust data exchange formats in use today and has become a standard part of most software systems. As a well-matured protocol, XMPP uses the XML data format to transport data over standard TCP/IP sockets and websockets, making the protocol and its data easy to use and understand. Any developer familiar with XML can immediately work with XMPP as no special data format or other proprietary knowledge is needed. Existing tools for creating, reading, editing, and validating XML data can all be used with XMPP without significant modification. The XML foundation of XMPP greatly simplifies integration with existing environments and eases the movement of data to and from the XMPP network.

Extending XMPP

The extensible nature of XML provides much of the extension support built into XMPP. Through the use of XML namespaces, the XMPP protocol can be easily used to transport custom data in addition to standard IM messages and presence information. Software developers and companies interested in the real-time exchange of data are using XMPP as an alternative to custom data transport systems.

The XMPP community publishes standard extensions called XMPP Enhancement Proposals (XEPs) through the XMPP Software Foundation (XSF). The XSF’s volunteer-driven process provides a way for companies creating innovative extensions and enhancements to the XMPP protocol to work together to create standard improvements that all XMPP users benefit from. There are well over 400 XEPs today covering a wide range of functionality, including security enhancements, user experience improvements and VoIP and video conferencing. XEPs allow the XMPP protocol to rapidly evolve and improve in an open, standards-based way.

XMPP Networks Explained

An XMPP network is composed of all the XMPP clients and servers that can reach each other on a single computer network. The biggest XMPP network is available on the Internet and connects public XMPP servers. However, people are free to create private XMPP networks within a single company’s internal LAN, on secure corporate virtual private networks, or even within a private network running in a person’s home. Within each XMPP network, each user is assigned a unique XMPP address.

Addresses - Just Like Email

XMPP addresses look exactly the same as email addresses, containing a user name and a domain name. For example, sales@acme.com is a valid XMPP address for a user account named “sales” in the acme.com domain. It is common for an organization to issue the same XMPP address and email address to a user. Within the XMPP server, user accounts are frequently authenticated against the same common user account system used by the email system.

XMPP addresses are generated and issued in the same way that email addresses are. Each XMPP domain is managed by the domain owner, and the XMPP server for that domain is used to create, edit, and delete user accounts. For example, the acme.com server is used to manage user accounts that end with @acme.com. If a company runs the acme.com server, the company sets its own policies and uses its own software to manage user accounts. If the domain is a hosted account on an Internet Service Provider (ISP) the ISP usually provides a web control panel to easily manage XMPP user accounts in the same way that email accounts are managed. The flexibility and control that the XMPP network provides is a major benefit of XMPP IM systems over proprietary public IM systems like Whatsapp, Telegram and Signal, where all user accounts are hosted by a third party.

Server Federation

XMPP is designed using a federated, client-server architecture. Server federation is a common means of spreading resource usage and control between Internet services. In a federated architecture, each server is responsible for controlling all activities within its own domain and works cooperatively with servers in other domains as equal peers.

In XMPP, each client connects to the server that controls its XMPP domain. This server is responsible for authentication, message delivery and maintaining presence information for all users within the domain. If a user needs to send an instant message to a user outside of their own domain, their server contacts the external server that controls the “foreign” XMPP domain and forwards the message to that XMPP server. The foreign XMPP server takes care of delivering the message to the intended recipient within its domain. This same server-to-server model applies to all cross-domain data exchanges, including presence information.

XMPP server federation is modeled after the design of Internet email, which has shown that the design scales to include the entire Internet and provides the necessary flexibility and control to meet the needs of individual domains. Each XMPP domain can define the level of security, quality of service, and manageability that make sense for their organization.

Conclusion

XMPP is open, flexible and extensible, making it the protocol of choice for real-time communications over the Internet. It enables the reliable transport of any structured XML data between individuals or applications. Numerous mission-critical business applications use XMPP, including chat and IM, network management and financial trading. With inherent security features and support for cross-domain server federation, XMPP is more than able to meet the needs of the most demanding environments.

2 posts - 2 participants

Read full topic

For over two decades, ProcessOne has been developing large-scale messaging platforms, powering some of the largest services in the world. Our mission is to build the best messaging back-ends imaginable–an exciting yet complex challenge.

We began with XMPP (eXtensible Messaging and Presence Protocol), but the need for interoperability and support for a variety of use cases led us to implement additional protocols. Our stack now supports:

• XMPP (eXtensible Messaging and Presence Protocol): A robust, highly scalable, and flexible protocol for real-time messaging.
• MQTT (Message Queuing Telemetry Transport): The standard for IoT messaging, ideal for lightweight communication between devices.
• SIP (Session Initiation Protocol): A widely used standard for voice-over-IP (VoIP) communications.
• Matrix: A decentralized protocol for secure, real-time communication.

A Distributed Protocol That Replicates Data Across Federated Servers

This brings me to the topic of Matrix. Matrix is designed not just to be federated but also distributed. While it uses the term “decentralized,” I find this slightly misleading. A federated protocol is inherently decentralized, as it allows users across different domains to communicate–think email, XMPP, and Matrix itself. What truly sets Matrix apart from XMPP is its data distribution model.

Matrix is distributed because it aims to ensure that all participating nodes in a conversation have a copy of that conversation, typically in end-to-end encrypted form. This ensures high availability: if the primary node hosting a conversation becomes unavailable, the conversation can continue on another node.

In Matrix, a conversation is represented as a graph, a replicated document containing all events related to a group discussion. You can think of each conversation as a mini-blockchain, except that instead of forming a chain, the events create a graph.

Resource Penalty: Computing and Storage

As with any design decision, there are trade-offs. In the case of Matrix, this comes with a performance penalty. Since conversations are replicated across nodes, the protocol performs merge operations to ensure consistency between the replicated data. The higher the traffic, the greater the cost of these merge operations, which adds CPU load on both the Matrix node and its database. Additionally, there is a significant cost in terms of storage.

If the Matrix network were to scale massively, with many nodes and conversations, it would encounter the same growth challenges as blockchain protocols. Each node must store a copy of the conversation, and the amount of replication depends on the number of conversations and nodes globally. As these numbers grow, so does the replication factor.

Comparison with XMPP

XMPP, on the other hand, is event-based rather than document-based. It processes and distributes events in the order they arrive without attempting to merge conversation histories. This simpler approach avoids the replication of group chat data across federated nodes, but it comes with some limitations.

Here’s how XMPP mitigates these limitations:

• One-on-One Conversations: Each user’s messages are archived on their server, keeping the replication factor under control (usually limited to two copies).
• Group Chats: If a chatroom goes down, the conversation becomes unavailable for both local and remote users. However, XMPP has strategies to reduce the need for data replication. Several servers implement clustering, making it possible to upgrade the service node by node. If one node is taken down (for maintenance, for instance), another node can take over the management of the chatroom.
• Hot Code Upgrades: Some servers, like ejabberd, allow hot code upgrades, which means minor updates can be applied without shutting down the node, minimizing downtime and the need for data replication.
• Message Archiving for MUC Rooms: Some servers offer message archiving for multi-user chat (MUC) rooms, but also allows users to store on their local server recent chat history in select MUC for future reference.
• Cluster Replication (ejabberd Business Edition): Chatrooms can be replicated within a cluster, ensuring they remain available even if a node crashes.

Thanks to the typically high uptime of XMPP servers, especially for clustered services, intermittent availability of servers in the network hasn’t posed a significant issue, so large-scale data replication hasn’t been a necessity.

What’s Next for XMPP?

This comparison suggests potential improvements for XMPP. Could XMPP benefit from an optional feature to address the centralized nature of chatrooms? Possibly. What if there were a caching and resynchronization protocol for multi-user chatrooms across different servers? This could enhance the robustness of the federation without the storage burden of full content replication, offering the best of both worlds.

What’s Next for Matrix?

Matrix, by design, comes with trade-offs. One of its key goals is to resist censorship, which is vital in certain situations and countries. That’s why we believe it is worth trying to improve the Matrix protocol to address those use cases. There’s still room to optimize the protocol, specifically by reducing the cost of running a distributed data store. We plan to propose and implement improvements on how merge operations work to make Matrix more efficient.

I’ll share our proposals in the next article.

—

As always, this is an open discussion, and I’d be happy to dive deeper into these topics if you’re interested.

The post Matrix and XMPP: Thoughts on Improving Messaging Protocols – Part 1 first appeared on ProcessOne.

This release comes with many improvements for Gajim’s Microsoft Store version. Translations are now available for all distributions again. Thank you for all your contributions!

What’s New

Gajim now detects if you installed it from the Microsoft Store. This allows Gajim to delegate updates to the Store rather than handling updates by itself. Detecting the install method also allowed us to apply a fix which prevented native notifications to work in Windows. Last but not least, viewing received images and download folders should now work properly on Windows.

What else happened

• Translations are available for all distributions again
• Typing indicator has been moved above the chat input
• Debug console received a proper search

Have a look at the changelog for a complete list.

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

Some languages are born performant, and later on tackle concurrency. Others are born concurrently and later build on performance. C or Rust system’s programming are examples of the former, Erlang’s Concurrency is an example of the latter.

A mistake in concurrency can essentially let all hell loose, incurring incredibly hard-to-track bugs and even security vulnerabilities, and a mistake in performance can leave a product trailing behind the competition or even make it entirely unusable to begin with.

It’s all risky trade-offs. But what if we can have a concurrent framework with competitive performance?

Let’s see how Erlang answers that question.

A look into scalable platforms

C or Rust are languages traditionally considered performant by compiling native machine instructions, enforcing manual memory management, and exposing semantics that map to that of the underlying hardware. Meanwhile, Erlang is a language famous for its top-notch concurrency and fault tolerance and was built to be that way. Lightweight processes, cheap message passing, and share-nothing semantics are some of the key concepts that make it a strength. Like everything in IT, there’s a wide range of trade-offs between these two problems.

A case of encoding and decoding protocol

An advantage of having a performance problem versus having a concurrency problem is that the former is much easier to track down. thanks to automated tooling like benchmarking and profiling. It’s a common path for Erlang. When you need performance, it offers a very easy-to-use foreign function interface. This is especially common for single-threaded algorithms, where challenges of concurrency or parallelism aren’t important and risks of a memory-unsafe language like C are minimal. The most common examples are hashing operations, protocol encoding and decoding like JSON or XML.

Messaging platforms

Many years ago, one of my first important contributions to MongooseIM, our extensible and scalable Instant Messaging server, was a few optimisations about JIDs, short for Jabber IDentifiers, the identifiers XMPP uses to identify users and their sessions. After an important cleanup of JID usage, I noticed in profiles that calls to encoding and decoding operations were not only extremely common but also suspiciously slow. So I then wrote my first NIF, implementing these basic and very simple operations in C, and later moving this code to its own repo.

Fast forward a few years, and I had the chance to revert to the original Erlang code for the encoding and later on for the decoding. The same very straightforward Erlang code has become a lot faster than the very carefully optimised C one. But this is a very simple algorithm, so, let’s push the limits to more interesting places.

The evolution of the Erlang runtime

OTP releases have been getting more and more powerful performance improvements, especially since the JIT compiler was introduced. To put things into context, when I made those NIFs back then, no JIT compiler was available at the time. Ever since the quest to beat C code has become feasible in a myriad of scenarios.

For example, one place where the community has put some emphasis on building ever more performant code was on JSON parsers. Starting from Elixir’s Jason and Poison, we also have Thoas, a pure-Erlang alternative. They all ran their benchmarks competing most dearly against jiffy, the archetypical C solution. Until recently a JSON module was incorporated directly into Erlang. See the benchmarks yourself, for encoding and decoding. It beats jiffy in virtually all scenarios, sometimes by a very good difference.

Building communities

Here’s a more interesting example. I’ve been working on a MongooseIM extension for FaceIT, the leading independent competitive gaming platform for online multiplayer PvP gamers. They provide a platform where you can find the right matching peers, that keeps the community healthy and thriving, making sure matches are fair and no cheating is allowed, and ultimately, a platform where you can build a relationship with your peers.

These communities are enabled by MongooseIM and need presence lists.

The challenge of managing presence for such a large community is two-fold. First, we want to reduce network operations by introducing pagination and real-time updates of only deltas, so that without any network redundancy your device can update the view on display. Then we want to be able to manage such large data structures within maximal performance.

Native code

This is archetypical: a very large data structure that requires fast updates is not where immutable runtime would shine, as “mutations” are in reality copying. So you consider a solution in a classical performant language, for example, C, or even better, a memory-safe one like Rust. Quickly we found a ready solution, a Rust implementation of an indexed sorted set was readily available. A very good option, probably the best around. Let’s have a measurement for reference: inserting a new element at any point in a set of 250K elements takes ~4μs. The question then is, can we give pure Erlang code a chance to compete against ~4μs?

Data structures

You can find more details about this endeavour in a guest blog I wrote for FaceIT. In a nutshell, the point of disadvantage is the enormous amount of copying that any mutation implies. So the first idea is to have a list of lists instead: this is pretty much a skip-list. A list of lists of lists is just a skip list with more lanes, and all these lanes require constant rebalancing.

Another data structure famous for requiring rebalancing is the balance binary tree and Erlang ships with an implementation of general balanced trees based on this research paper by Prof. Arne Andersson. This will be our candidate. The only thing missing is operations on indexes, as we want to know the position modifications that took place. Wikipedia has a hint here: Order Statistic Trees. In turn, extending `gb_sets` to support indexes took not more than a couple of hours, and we’re ready to go.

Benchmarking

5μs!

Adding an element at any point of a 250K list takes on average 5μs! In pure Erlang!

The algorithm has an amortised runtime of `O(1.46*log(n))`, and the logarithm base two of 250K is ~8, that is, on average it will take 12 (exactly 11.68) steps to apply any operation. And including the most unfortunate operations that required the entire 12 steps and some rebalancing, the worst case is still 17μs.

What about getting pages? Getting the first 128 elements of the set takes 92μs. To add a bit more detail, the same test takes 100μs on OTP26, that is, by only upgrading the Erlang version we already get an 8% performance improvement.

Conclusion

We’ve seen a scenario with MongooseIM JIDs where once code is rewritten in C for performance reasons could simply be reverted to the original Erlang code and beat C’s performance; a case with JSON parsing where well-crafted Erlang code could beat the unbeatable C alternative; and at last, a problem where a very large data structure once written in Rust wasn’t necessary as a simple pure-Erlang implementation was just as competitive.

We have a runtime that was born concurrently and evolved to be performant. We have a runtime that is memory-safe and makes the enormously complex problem of concurrency and distribution easy, allowing the developer to focus on the actual business case while massively reducing the costs of support and the consequences of failure. A runtime where performance does not need to be sacrificed to achieve these things. A runtime that enables you to write messaging systems (WhatsApp, Discord, MongooseIM), websites (Phoenix and the insanely performant JSON parsing), and community platforms (FaceIT).

We know how to make this all work, and how to keep the ecosystem evolving. If you want to see the power of Erlang and Elixir in your business case, contact us!

The post Erlang Concurrency: Evolving for Performance appeared first on Erlang Solutions.

Welcome to the series “Elixir, 7 Steps to Start Your Journey”, dedicated to those who want to learn more about this programming language and its advantages.

If you still don’t have much experience in the world of programming, Elixir can be a great option to get started in functional programming, and if you have already experimented with other programming languages, not only will it be easier for you, but I am sure that you will find the differences between programming paradigms interesting.

In any case, this series aims to help you have fun exploring Elixir and find enough reasons to choose it for your next project. I hope you enjoy it!

Why a series dedicated to Elixir?

Before fully entering the topic, I’ll share a little about my experience with Elixir and why I decided to write this series.

I discovered Elixir in 2018, I would say, by chance. Someone told me about this programming language and how wonderful it was. At that time, I had no idea, nor had I had any contact with functional programming beyond university internships. However, a few months later, ElixirConf took place in Mexico, so I attended to learn more about this technology.

The first thing that captivated me was how friendly the community was. Everyone was relaxed, having a lot of fun and sharing. The atmosphere was incredible. So, I joined this world and started collaborating on my first project with Elixir.

The start of the journey

At first, I didn’t have a good time since the project level was not that simple. 

The project used Phoenix Channels, and until then, I had not been involved in a project with real-time communication features. But to my surprise, it didn’t take me that long to understand how everything fits together; the code patterns were intuitive, there was a lot of documentation available, the syntax was lovely, and there were no files with hundreds of thousands of lines of code that made them difficult to understand.

Many years have passed since that beginning, and I continue to enjoy programming with Elixir and being surprised by all the new things emerging in this community. So, I decided to write a series of posts to share these experiences that I hope will be helpful to those who are just getting to know this programming language. Spoiler: you won’t regret it.

That being said, let’s talk about Elixir.

Let’s talk about Elixir!

“Elixir is a dynamic, functional language for building scalable and maintainable applications.”

José Valim created it in 2012, and version 1.0 was released in 2014. As you can see, it is a relatively young programming language supported by an excellent foundation, the BEAM.

Elixir runs on the Erlang virtual machine known as BEAM. Some features of this machine are:

• Simultaneously, it supports millions of users and transactions.
• It has a mechanism to detect failures and recover from them.
• It allows you to develop systems capable of operating without interruptions forever!
• Allows real-time system updates without stopping or interrupting user activity.

All these properties are transmitted to Elixir; plus, as I mentioned before, the syntax is quite intuitive and pleasant, and many resources are available, so creating a project from scratch to start experimenting will be a piece of cake.

It’s been a short introduction, so for now, it’s okay if you’re not sure what role BEAM plays in this series. In the next chapter, we will delve into it.

We only have to consider when we talk about Elixir;  it is also essential to know the fundamentals that make this programming language such a solid and reliable option. And if you don’t have much experience with functional programming, don’t worry; Elixir will help you understand the concepts while putting them into practice.

What topics will the series cover?

This series will cover the essential topics to help you develop a project from scratch and understand what is behind Elixir’s magic. 

The chapters will be divided as follows:

1. Erlang Virtual Machine, the BEAM
2. Understanding Processes and Concurrency
3. Libraries and Frameworks
4. Testing and Debugging
5. The Elixir Community
6. Functional Programming vs. Object-Oriented Programming
7. My first project with Elixir!

Is this series for me?

This series is for you if you:

•  Are starting in the web programming world and don’t know which language to choose as your first option.
• Already have programming experience, but want to explore new options and learn more about functional programming.

Or if you are simply looking for a programming language that allows you to learn and have fun at the same time.

Next chapter

In the next post, “Erlang Virtual Machine, the BEAM”, we will talk about Erlang, the elements that make the BEAM so powerful, and how Elixir benefits from it. Don’t miss it! In the meantime, drop the team a message if you have any pressing Elixir questions.

The post Elixir, 7 steps to start your journey appeared first on Erlang Solutions.

Gajim 1.9.4 integrates XMPP Providers, supports Hats and brings many improvements and bug fixes. Thank you for all your contributions!

What’s New

Hats

Thanks to our contributor @nicoco, Gajim received support for Hats (XEP-0317). Hats allow to assign roles to group chat participants, i.e. “Support”, “Expert” or really anything you like to assign. Gajim displays Hats in the list of participants.

XMPP Providers integration

XMPP (Extensible Messaging and Presence Protocol) is like a common language both your and your chat partner’s app speak to each other. Similar to email, there is a service provider managing your account and messages. That provider speaks XMPP too.

But some XMPP providers support functionalities that other providers do not. Some support registrations via your app and some only via their websites. Some provide more space for sharing media than others or store them longer than others. That is where the XMPP Providers project comes into play. The project offers a curated list of XMPP providers, which makes it easy for you to find a suitable provider. All properties of the included providers are automatically checked on a daily basis and updated if needed. When creating a new account with Gajim, you will now be offered suggestions taken from this curated list.

What else happened

• You can now choose if you want to synchronize group chats between your chat apps
• Message search now offers an interface for filtering
• Message loading performance has been improved
• Group chat search results show more infos (reachable via Start Chat > Group chat search)
• Typing indicator has been moved to the bottom of the chat
• A bug which caused the chat to become very wide if messages contained long links has been fixed

Have a look at the changelog for a complete list.

For our package maintainers

Attention to all package maintainers, this release changes how Gajim is build. Please check README.md for more information.

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

The Ignite Realtime community is happy to be able to announce the immediate availability of version 4.9.0 of Openfire, its cross-platform real-time collaboration server based on the XMPP protocol!

As compared to the previous non-patch release, this one is a bit smaller. This mostly is a maintenance release, and includes some preparations (deprecations, mainly) for a future release.

Highlights for this release:

• A problem has been fixed that caused, under certain conditions, a client connection to be disconnected. This appears to have affected clients sending multi-byte character data more than others.
• Community member Akbar Azimifar has provided a full Persian translation for Openfire!

The list of changes that have gone into the Openfire 4.9.0 release has some more items though! Please review the change log for all of the details.

Interested in getting started? You can download installers of Openfire here. Our documentation contains an upgrade guide that helps you update from an older version.

The integrity of these artifacts can be checked with the following sha256sum values:

7973cc2faef01cb2f03d3f2ec59aff9b2001d16b2755b4cc0da48cc92b74d18a  openfire-4.9.0-1.noarch.rpm
a0cd627c629b00bb65b6080e06b8d13376ec0a4170fd27e863af0573e3b4f791  openfire_4.9.0_all.deb
bf62c02b0efe1d37fc505f6942a9cf058975746453d6d0218007b75b908a5c3c  openfire_4_9_0.dmg
1082d9864df897befa47230c251d91ec0780930900b2ab2768aaabd96d7b5dd9  openfire_4_9_0.exe
12a4a5e5794ecb64a7da718646208390d0eb593c02a33a630f968eec6e5a93a0  openfire_4_9_0.tar.gz
c86bdb1c6afd4e2e013c4909a980cbac088fc51401db6e9792d43e532963df72  openfire_4_9_0_x64.exe
97efe5bfe8a7ab3ea73a01391af436096a040d202f3d06f599bc4af1cd7bccf0  openfire_4_9_0.zip

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 Mastodon or X

6 posts - 4 participants

Read full topic

We have now released version 1.4.1 of the HTTP File Upload plugin!

This plugin adds functionality to Openfire that allows clients to share files, as defined in the XEP-0363 ‘HTTP File Upload’ specification.

This release brings two changes, both provided by community members (thanks!):

• Vladislav updated the Ukrainian translation;
• Anno created an admin console page for this plugin.

As always, your instance of Openfire should automatically make available to update in the next few hours. Alternatively, you can download the new release of the plugin at the HTTP File Upload plugin’s archive page.

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

1 post - 1 participant

Read full topic

Earlier today, we blogged about a boatload of Openfire plugins for which we made available maintenance releases.

Apart from that, we’ve also made a more notable release: that of the Hazelcast plugin for Openfire.

The Hazelcast plugin for Openfire adds clustering support to Openfire. It is based on the Hazelcast platform.

This release brings a major upgrade of the platform. It migrates from version 3.12.5 to 5.3.7.

As a result, replacing an older version of the plugin with this new release requires some careful planning. Notably, the configuration stored on-disk has changed (and is unlikely to be compatible between versions). Please refer to the readme of the plugin for details.

A big thank you goes out to community member Arwen for making this upgrade happen!

As usual, the new version of the plugin will become available in your Openfire server within the next few hours. Alternatively, you can download the plugin from its archive page.

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

1 post - 1 participant

Read full topic

The Ignite Realtime community is gearing up for a new release of Openfire. In preparation, we have been performing maintenance releases for many Openfire plugins.

These Openfire plugin releases have mostly non-functional changes, intended to make the plugin compatible with the upcoming 4.9.0 release of Openfire:

• Push Server 1.1.0
• User Service 2.1.3
• User Creation 1.4.1
• Broadcast 1.9.3
• Jinge Nodes 0.2.2
• FastPath 4.5.1
• ClientControl 2.1.9
• Blacklist Spam 1.0.2
• Push Notification 1.0.1
• Bookmarks 2.6.0
• Certificate Manager 1.2.0

The following plugins have (also) seen minor functional upgrades:

• DbAccess 1.3.0: now remembers recently executed queries.
• External Service Discovery 1.0.3: fixes behaviour around an error edge case.
• XML Debugger 1.8.0: now compatible with Openfire 4.8.0, and includes a tool to send raw XMPP from the admin console.
• Presence 1.7.3: fixes a bug with online users for the ‘text’ type of query
• Monitoring 2.6.0 fixes an Oracle database issue, and erroneous index rebuilding status messages
• Galene 0.8.1 updates the embedded Galene binary to version 0.8.1

As usual, the new versions of the plugins should become available in your Openfire server within the next few hours. Alternatively, you can download the plugins from their archive pages, which are linked to above.

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

1 post - 1 participant

Read full topic

We hope you’ve been having a good summer (at least if you’re up here in the northern hemisphere). Today we’re back with a new release of the self-hosted Snikket server software.

This software is what’s at the core of the Snikket project - a self-hostable “personal messaging server in a box”. If you wish for something like Messenger, WhatsApp or Signal, but not using their servers, Snikket is for you. Once deployed, you can create invitation links for family, friends, colleagues… any kind of social group is the main target audience for Snikket. The invitation links walk even the least-technical people safely through downloading the Snikket app and joining your private Snikket instance.

If you’re not a self-hoster, we also have a hosted version which lets you get your own instance started in just a few clicks.

What’s new

Some highlights of what changes this release brings:

Invitations

We’ve made a number of small but important improvements to the way invitations are created and managed.

For example, people often told us that after creating a few invitation links and sending them out, they would forget who each link was created for and why. Now Snikket allows you to attach a brief custom note to invitations, visible only to admins in the list of pending invitations, making it easy to see at a glance who has yet to accept their invitation.

Example of the new invitation form, which allows adding an optional comment

Meanwhile we’ve added an important feature that was missing from invitations - you can now specify the role that will be applied to anyone who joins using a given invitation link. Previously, if you wanted to set up e.g. a child with a “limited” account, they would first join as a normal user, and then you would need to navigate to the user management page and assign them the “Limited” role. With this new release, you are able to assign the role directly when you create the invitation, which is much simpler and more secure.

Invitations now allow selecting the user’s role before they sign up

A really handy feature we’ve added is the ability to share the invitation link directly through other apps, if your web browser supports it (which most mobile browsers do). This can make it much easier to send invitation links via SMS/email or other apps in a couple of taps, without manual copy and pasting.

An example of the invitation sharing feature in Firefox on Android

Changes to blocking

Though uncommonly used on private servers, it’s nevertheless possible to block people in Snikket. When you do this, the blocked person would receive a delivery error when attempting to send a message to someone who had blocked them. From this error, it’s possible to deduce that you have been blocked.

Based on feedback, we have adjusted this so that no delivery error is sent to people you have blocked.

Technical stuff

We’ve added a few new things that are not present in the interface, but are of interest to people deploying Snikket.

It is now possible to adjust the port of the STUN/TURN server. By default this adjusts the port of the internal server that is provided with Snikket, but if you have configured an external TURN server then it means you are now able to host that on non-standard ports too.

Self-hosted instances are now able to use International Domain Names (IDNs), i.e. domain names that contain unicode characters. This feature is not yet available for instances hosted by Snikket, but let us know if you’re interested.

Other

Of course these are just the highlights. We’ve also improved a bunch of things under the hood, either in Snikket or as part of Prosody, the open-source project which powers Snikket’s chat connections, and has been updated in this new release.

For more information, and more changes in this release, check out the release notes.

Upgrading

Upgrading an existing installation is super simple and takes less than a minute! You can find instructions in the ‘Upgrading’ section of the release notes.

---

If you have any questions or feedback about the new release, come and join the discussion in our community chat.

We hope you enjoy Snikket. Happy chatting!