Erlang Solutions launched SAFE, a Security Audit for Erlang in the fall of 2023. We extended the analysis for Elixir in the spring of 2024 and now, SAFE officially supports Phoenix Liveview, which means a SAFE scan is now looking for vulnerabilities common in Phoenix web applications.

What is SAFE?

SAFE is a security scanning tool for Erlang, Elixir and Phoenix (LiveView) codebases. It works by loading and analysing your code, without running it. SAFE conducts an in-depth analysis of codebases, which can help you and your company to elevate your cybersecurity.

Supporting Phoenix LiveView

Now, as of the 1.3.0 release of SAFE, we support Phoenix LiveView, which means we can check for the following vulnerabilities:

• Cross Site Scripting (XSS)
• Cross Site Request Forgery (CSRF)
• Cross-Site WebSocket Hijacking (CSWSH)
• SQL Injection (with Ecto support)
• Denial of Services (DoS)
• Session leakage (unprotected session information)
• Session fixation (session ID renewal issues)
• Session hijacking
• Content Security Policy (CSP)

On-Prem report visualisation

With the release of the new SAFE version, a new SAFE product flavour was also launched, called SAFE OnPrem. This solution allows companies to host a centralised security report viewer that engineers and security specialists can access via the web interface.

Overview page of an example report:

User management:

Running SAFE

If you are interested in running SAFE on your code base, please check out our Quick Start Guide and contact the SAFE team . You can also drop us a message if you maintain an open source project, as you may be eligible for a free SAFE license.

More information about Open Source licensing can be found in our announcement blog post .

The post SAFE for Elixir: Phoenix LiveView appeared first on Erlang Solutions .

The moment a fintech product shifts from prototype to production is often when the cracks appear. Tiny shortcuts. Half-formed assumptions. Decisions made because “we’ll fix it later.” They all return, and they return quickly.

At first, everything looks fine. The demo works. Early users onboard without trouble. In turn, confidence builds. Then real volume arrives with real expectations, and the product that once felt promising starts to resist growth.

The (Minimum Viable Product) MVP phase should have revealed the weak points. It should have been the place to break things safely. But often it becomes a race to launch without learning much at all. Speed gets mistaken for insight, and the cost shows up when the stakes are highest.

For teams serving SMEs, the risk is even greater.

The Scaling Problem: When “go fast” Stops Working

Fintechs focused on small businesses usually start strong. They prove demand, attract their first cohorts and show early traction.

Then comes the real hurdle: scale.

Small and medium-sized businesses don’t want flash. They want reliability, simplicity and absolute confidence that their money, payments, payroll and data won’t break at the wrong moment. According to The Payment Association , with 5.51 million SMEs representing 99% of UK businesses alone, that demand is huge.

Picture thousands of businesses depending on your platform every minute. If your stack can’t handle load variations, regulatory nuances across regions or the complexity of business onboarding, growth becomes dangerous.

And the consequences aren’t theoretical. One industry review found that hidden infrastructure issues in fintech quietly drain 10–20% of capital and create terrifying downtime costs.

When an SME loses access to its financial tools, even for an hour, it can feel like a lost lifeline.

Scenario in action

Let’s imagine a fintech that nails product-market fit in one region. SMEs love it. Growth follows. Then expansion begins, and strain appears immediately.

The original build never accounted for multi-region onboarding, regulatory differences, load variation or different payment rails. The product did not fail. Success exposed everything the MVP never tested.

This often happens when early architecture is not prepared for real-world complexity. As usage expands, the gaps surface quickly.

Why MVP habits collapse at SME scale

In the rush to market, fintechs often use the MVP mindset (launch early, iterate fast). That works for consumer apps but is riskier for platforms serving SMEs, where downtime, data inconsistency and compliance are costly.

Research shows only around 43% of UK SMEs accessed external finance in Q2 2024, and just 44% of applications were successful. Given this tight margin of trust and reliability, the fintech solving SME problems must get the architecture right from early on.

SMEs often adopt fintech solutions fast: one study found that 65% of UK SME decision-makers believe they need the agility of fintech to enable their growth plans. The opportunity is there; what is less guaranteed is the product foundation. When the MVP is built purely for launch speed, the next stage of growth can expose fragilities.

Common challenges for SME-serving fintechs:

• Lack of monitoring for thousands of SME users rather than hundreds
  
• Compliance demands when onboarding business accounts vs consumer
  
• Manual operational workarounds that don’t scale
  
• Infrastructure built for single region, not multi-market
  

These issues rarely show up in a prototype. They surface the moment production load, regulation and real SME behaviour collide.

Building for production: What matters most

Turning a prototype into a platform that serves millions of SMEs requires architectural discipline. It starts with asking a simple question: what happens when this grows?

Technology choices matter. Systems built on concurrency, resilience and fault tolerance give fintechs room to scale without rebuilding from scratch.

Platforms using the BEAM virtual machine and languages like Elixir rely on lightweight processes and supervision strategies that keep systems stable under heavy load. Adopting these foundations early means your prototype does not have to be replaced. It evolves.

And SMEs feel that difference.

What this means for fintech SMEs (and their customers)

When a fintech platform is designed with SMEs in mind, the impact is felt inside the company and in the daily routines of customers.

Reduced downtime and more stability

SMEs cannot pause operations because a platform is struggling. Payroll, payments and transactions move continuously. Downtime is costly and trust disappears quickly. A system designed to scale helps avoid those fragile moments and reduces the need for constant emergency fixes.

Lower cost of change

When the architecture anticipates growth, teams spend less time rebuilding and more time improving the product. Smoother onboarding, integrated payments and better analytics become easier to deliver. Languages like Elixir support this quietly, allowing teams to make changes without breaking the foundations.

Simpler compliance and clearer audit-ability

Serving SMEs means navigating business account requirements, lending oversight and payment regulations. Systems built to production standards make compliance part of the design rather than a collection of manual steps.

Faster deployment and steady iteration

Fintechs must keep innovating without sacrificing stability. Lightweight processes and strong supervision make frequent, safe deployments possible. Stability and progress can coexist.

A better experience for SME customers

When the platform works reliably, teams can focus on problems that matter: cash-flow visibility, credit access, smoother invoicing and efficient banking. SMEs notice. 85 percent of UK SMEs would consider choosing a fintech over a traditional bank because the digital tools are stronger.

To conclude

Fintechs serving SMEs rarely struggle because the idea is weak. They struggle when the technology behind that idea cannot keep up with real businesses. The prototype is only the starting point. Production is where reliability becomes a promise you must keep.

SMEs run on trust, cash flow and predictable systems. When a platform fails, it affects salaries and core operations.

This is why resilient foundations matter. Using a programming language like Elixir, built on BEAM’s concurrency and fault-tolerance strengths, helps teams create systems that stay steady even as demand rises. It gives product teams room to improve instead of constantly patching.

The SME opportunity is significant. The question is whether your platform has the strength to grow with it. If you’re a fintech and would like to build with resilience in mind, let’s talk .

Turning fast- moving prototypes into stable, scalable solutions is far easier when you make the right choices early.

The post From Prototype to Production: Scaling Fintech for SMEs appeared first on Erlang Solutions .

We hear this too often: “XMPP uses XML. It should use JSON—it’s more modern.”

The logic seems straightforward: JSON came later, so it must be better. But better for what, exactly?

JSON became successful because it’s the standard serialization format for JavaScript. That made it convenient for browser-based applications.

Does that make it the universal format for every protocol? Of course not.

Consider this: browsers still use HTML to organize web pages, not JSON. Same with CSS. Why? Because using JSON for everything would be a nightmare.

XML remains the best format for representing trees—deep hierarchies of nested data. JSON handles flatter structures well, but good messaging protocols are extensible: extensions can be embedded at different levels and composed together, like Lego bricks. That’s where XML shines.

The Performance Myth

Another common claim: XMPP’s XML is more complex than JSON, so it must be much slower.

In practice, XMPP chat platforms are snappier, with remarkably low message latency. How?

XMPP clients don’t parse XML the way most people assume. They’re not building massive DOM trees in memory, like a browser loading a page. Instead, they use stream-based parsing—XML arrives, gets parsed incrementally, and converts directly into native data structures.

This is especially true in browser environments, where XMPP streams run over WebSockets, which naturally frames the XMPP protocol. That’s why you are never actually working with XML trees consuming large chunks of memory. Modern implementations like XMPP.js go further and use LTX—a lightweight parser built specifically for XMPP’s streaming model—rather than the browser’s DOM parser. The result: developers work with JSON-like objects anyway. The wire format becomes invisible to your application code.

XML brings three key advantages:

• Built-in extensibility with validation via XML Schemas
• Clean namespace management for XEPs: when the protocol needs to evolve, you can change the namespace of an extension, making versioning explicit and backward compatibility manageable
• 25+ years of mature tooling and battle-tested parsers

These matter when you’re building federated systems that need to evolve over time and need to stay compliant over time. The XMPP federation is a huge ecosystem of servers that can talk to each other, relying on different server implementations and are not always up to date. Still, the federation works, and we too often forget that this is a great achievement in itself.

Real performance bottlenecks in XMPP deployments come from elsewhere entirely: network latency, database optimization for roster and message storage, custom module performance, external components, or clustering and routing logic.

The myth persists because XML looks verbose when you read it. But visual verbosity has almost no correlation with parsing performance. Modern CPUs parse XML and JSON at nearly identical speeds for typical XMPP message sizes. Any difference vanishes in a real-world client.

Where the Real Complexity Lives

XMPP does have genuine complexity—but it’s not the wire format. It’s the protocol depth and the extensive XEP ecosystem with hundreds of extensions. That’s a real learning curve.

Consider XMPP when these factors matter to you:

• Federation across organizational boundaries
• Open standards and avoiding vendor lock-in
• Protocol stability that won’t break in three years
• Extensibility without forking the protocol

If those resonate, the wire format should be the least of your concerns.

We’ve been building XMPP systems for over 25 years. The XML performance question comes up often in early conversations. Every single time, we end up optimizing ejabberd configuration, clustering, architecture, client protocol usage, and databases instead.

Thinking about XMPP for your next project? Reach out during the design phase. We’ll help you avoid the actual bottlenecks.

The Smack developers are happy to announce the availability the first release candidate (RC) of Smack 4.5.0.

The upcoming Smack 4.5 release contains many bug fixes and improvements. Please consider testing this release candidate in your integration stages and report back any issues you may found. The more people are actively testing release candidates, the less issues will remain in the actual release.

Smack 4.5.0-rc1 is now available on Maven Central .

1 post - 1 participant

Read full topic

Signal improved its protocol to prepare encrypted messaging for the quantum era.

They call the improvement “Triple Ratchet” (or SPQR = Signal Post-Quantum Ratchet).

If history repeats itself, this could become the next open standard for secure messaging.

Signal (formerly Open Whisper Systems) created the Double Ratchet protocol in 2013–2014, introduced in TextSecure v2 in February 2014. They packaged it into the open source Signal Protocol. It became the mainstream standard for end-to-end encrypted messaging. XMPP adopted it (OMEMO, developed in 2015). Matrix adopted it (Olm/Megolm implements Double Ratchet concepts).

The problem is that current encryption methods could break when quantum computers get powerful enough, so Signal built Triple Ratchet to protect against that.

Most messaging companies are preparing for this but I noticed that WhatsApp has no public roadmap for the adoption of quantum resistance protocols. They use the Signal Protocol for encryption, so they may simply wait for the result of Signal’s work to adopt the new approach.

It is much heavier to implement, so I am wondering if Triple Ratchet follows the same path as Double Ratchet and gets widespread adoption.

If open protocols like XMPP and Matrix adopt it, it may be huge for European messaging independence.

What’s your take? Do you think quantum resistance will become a mandatory feature for end-to-end encrypted messaging platforms in the next couple of years?

Good news for anyone building messaging infrastructure in Europe: Denmark&aposs Council presidency is abandoning mandatory detection orders in the Child Sexual Abuse Material (CSAM) proposal for now. The proposal was nicknamed "Chat Control" because it was invasive, requiring platforms to scan all message content. To do that, it would have required bypassing end-to-end encryption, practically creating a surveillance infrastructure.

They gave up after Germany and other EU countries blocked the message scanning obligation. They abandoned plans to put the text to a vote in the Council of the European Union in October as they had hoped. Now, they propose to return to the previous status quo .

It&aposs a relief for companies working on open and standards-based infrastructure. As I&aposve already explained, mandatory scanning is technically impossible to enforce for federated protocols like XMPP and Matrix . Europe&aposs decentralized messaging ecosystem would have been threatened, and the law would have been ineffective at preventing illegal data exchange, as encryption can always be applied outside of the chat application.

I know this is the type of fight that is never really over, but still, it is nice to see that sometimes sanity can prevail.

The Erlang Solutions team has been creating webinars that share knowledge, spark ideas, and celebrate the BEAM community. Each one offers a chance to explore new tools, hear fresh perspectives, and learn from the people building scalable and reliable systems every day.

If you haven’t tuned in yet, here’s a look at some of our recent sessions, full of practical insights and new thinking shaping the future of the BEAM.

SAFE for Elixir: Strengthening Security for Elixir and Erlang

In SAFE for Elixir , Robert Fiko and Mohamed Ali Khechine from the SAFE team talk about what it really means to build secure software.

They introduce SAFE for Elixir, a tool created with researchers at Eötvös Loránd University , that helps developers spot and fix vulnerabilities before they cause problems. It’s an honest and practical session about weaving security into your development process and making it part of your everyday workflow.

Messaging in Regulated Markets: Compliance from Day One

Compliance isn’t the most exciting part of building software, but it’s one of the most important. It’s also easy to leave until the end, and that’s where the problems usually start.

In Messaging in Regulated Markets: Compliance from Day One , Piotr Nosek explores what happens when you treat compliance as part of the design process instead of a last-minute fix. He also looks at how MongooseIM helps teams meet tough standards like GDPR, HIPAA, and NHS, while still building modern messaging tools with encryption, notifications, and video calls.

Gleam’s Interoperability with Erlang and Elixir

Gleam’s Interoperability with Erlang and Elixir is a hands-on look at how this type-safe language fits into the BEAM family.

Raúl Chouza uses a live Tic-Tac-Toe demo to show how Gleam works seamlessly alongside Erlang and Elixir, mixing dependencies and even pulling in modules like Phoenix LiveView. It’s a relaxed and engaging session that shows how developers can experiment across languages and still enjoy all the reliability the BEAM has to offer.

What You May Not Know About with

Every Elixir developer has come across with , but not everyone has taken the time to see what it can really do. In What You May Not Know About with , Brian Underwood and Adilet Abylov take a closer look at one of Elixir’s most overlooked features.

They show how it can make code cleaner, easier to follow, and far more expressive when it comes to handling complex logic. The session walks through common mistakes, explores ways to manage pattern matching, and shares practical tips for better error handling, all delivered in a way that makes you want to jump back into your editor and try it out.

Women in Elixir

Women in Elixir is a celebration of the people driving change across the BEAM community. Lorena Mireles shares insights from the Women in BEAM survey and her own experience in the industry, offering a thoughtful look at progress, opportunities, and the power of representation.

She also highlights how mentorship, community events, and visibility can help more women thrive in tech and why inclusion benefits everyone.

Learning through our webinars

These webinars show what makes the BEAM community unique: a mix of curiosity, openness, and a constant drive to improve how we build and collaborate. They reflect the depth of knowledge across Erlang, Elixir, and Gleam, and the passion that keeps this ecosystem evolving.

You can check out these sessions and more on our webinars page .

The post ​​Expert Insights from Our Latest Webinars appeared first on Erlang Solutions .

At Erlang Solutions, our support for the BEAM community is long-standing and built into everything we do. From contributing to open-source tools and sponsoring events to improving security and shaping ecosystem standards, we’re proud to play an active role in helping the BEAM ecosystem grow and thrive.

One way we’re putting that support into action is by offering free CI/CD-based security audits for open-source Erlang and Elixir projects. These audits help maintainers identify and fix vulnerabilities early, integrated directly into modern development workflows.

What the Free CI/CD Audits Offer

Our free CI/CD security audits for open source projects are powered by SAFE (Security Audit for Erlang/Elixir) , a dedicated solution built to detect vulnerabilities in Erlang and Elixir code that could leave systems exposed to cyber attacks.

The CI/CD version of SAFE integrates directly into your development pipeline (e.g. GitHub Actions, CircleCI, Jenkins), enabling you to scan for vulnerabilities automatically every time code is committed or updated. This helps projects:

• Detect issues early, before they reach production
  
• Maintain a more secure and resilient codebase
  
• Improve visibility of risks within day-to-day workflows
  

Results are delivered quickly– typically within a few minutes. For larger codebases, it may take up to 20–30 minutes. The feedback is designed to be clear, actionable, and minimally disruptive.

Open source maintainers can request a free license by emailing safe@erlang-solutions.com and including a link to their repository. Once approved, we provide a SAFE license for one month or up to a year, depending on the project’s needs, at no cost.

For more information, read our full terms and conditions .

Expert-Led Audits for Production BEAM Systems

SAFE is just one way we help teams build secure, resilient systems. We also offer hands-on audit services for production systems, including:

• Code reviews focused on clarity, maintainability, and best practices
  
• Architecture assessments to help ensure systems are scalable and fault-tolerant
  
• Performance audits to identify bottlenecks and optimise how systems behave under load

These services are delivered by our in-house experts and are a great fit for teams working on complex or business-critical systems. They also pair well with SAFE for a full picture of how systems are running and how they could be even better.

Of course, supporting the BEAM community goes beyond security and audits. Our involvement spans education, events, and long-term ecosystem development.

“We’re proud to support the BEAM ecosystem not just with code, but with the infrastructure and insights that help it grow stronger,” says Zoltan Literati, Business Unit Leader at Erlang Solutions Hungary.

“Our free audits offer real, practical value to maintainers working in open source. It’s one of the ways we’re giving back to the community.”

A Broader Commitment to the BEAM Community

The BEAM ecosystem continues to grow across languages like Erlang, Elixir and Gleam, driven by a global community of developers, maintainers, educators and advocates. Erlang Solutions is proud to contribute across multiple fronts, including:

• Sponsoring various conferences, including Code Sync
• Supporting the Erlang Ecosystem Foundation (EEF) , including participation in working groups focused on security, documentation, interoperability, and tooling
• Backing inclusion-focused initiatives such as Women in BEAM
• Sharing learning resources, contributing to open source libraries, and facilitating knowledge exchange through meetups, blogs and webinars
  

Our role is to support the ecosystem not only through expertise, but through action, and to help ensure that BEAM-based systems are not only scalable and reliable, but secure.

To learn more about our free CI/CD security audits or how we support the BEAM community, visit erlang-solutions.com .

The post Supporting the BEAM Community with Free CI/CD Security Audits appeared first on Erlang Solutions .

After twenty-five years, XMPP (Extensible Messaging and Presence Protocol) is still here. Mature, proven, modular, and standardized, it may well be the most solid foundation available today to build the future of messaging.

And now, XMPP is more relevant than ever: its resurgence is driven by European digital sovereignty efforts, renewed focus on interoperability, and the growing need for long-term, vendor-independent infrastructure.

Against this backdrop, the recent funding round around XMTP (Extensible Message Transport Protocol) , a newly launched blockchain-based protocol marketed as a universal messaging layer, raises questions. The name clearly evokes XMPP, yet there is no technological or community connection. And while XMPP could easily serve as a transport layer for blockchain-integrated messaging, XMTP chooses to ignore this legacy and start anew .

So the real question is:
Why rebuild from scratch when a solid, extensible foundation already exists?

A Protocol That Never Went Away

XMPP is an open protocol for real-time messaging, designed from the start for federation and decentralization. Standardized by the IETF (RFC 6120, 6121, 7622…), it has powered mission-critical systems for decades: enterprise communication, mobile apps at scale, online games, IoT control platforms.

What makes XMPP especially powerful is not just its architectural simplicity, but its modular extensibility . The protocol evolves through an ecosystem of open specifications (XEPs), covering:

• End-to-end encryption (OMEMO, OTR)
• Multi-device synchronization (Message Archive Management)
• Group chat with subscriptions (MUC and MUCSub)
• PubSub (XEP-0060) for real-time data and events
• Interoperability bridges (SIP, MQTT, Matrix)
• And more…

XMPP has never stopped evolving . Dozens of new extensions are proposed every year. It remains one of the most adaptable foundations for building secure, federated, and future-ready messaging systems.

XMTP: A New Protocol with a Familiar Name, but a Different Approach

XMTP is a blockchain-native messaging protocol developed by Ephemera. It aims to connect wallets and dApps, leveraging decentralized infrastructure (libp2p, IPFS-style storage) and cryptographic identities.

The ambition is clear: to build a censorship-resistant, peer-to-peer messaging layer for Web3, rooted in crypto-native identity and cryptography.

However, the naming is misleading. In an older interview , XMTP co-founder Matt Galligan said the name is a blend of SMTP and XMPP. It was chosen to evoke familiarity, perhaps even as a tribute. But the result is confusing : XMTP is not an extension, evolution, or even distant cousin of XMPP. There is no shared architecture, no interoperability, no community overlap.

Why This Matters Right Now

This naming issue would be minor if it weren’t happening at a critical time for protocol design . Governments, especially in Europe, are actively exploring how to regain control over digital infrastructure. Messaging is central to this effort, especially with upcoming interoperability mandates, data sovereignty requirements, and the need for long-term maintainability.

XMPP is uniquely well-positioned to meet these needs. It is mature, open, extensible, and governed through transparent standards. It has a community of engineers, operators, and developers actively maintaining and evolving it.

Instead of inventing closed messaging stacks around new ecosystems, the more pragmatic move would be to build on robust, extensible layers like XMPP :

• Need to integrate blockchain identities? XMPP can map public keys or wallet identifiers through custom namespaces or JIDs.
• Need cryptographic message-level guarantees? XMPP already supports message metadata, signatures, and encryption.
• Need better privacy ? XMPP can be run over privacy-preserving transports like Tor.

In short: XMPP can serve as a transport layer for Web3 communication without discarding two decades of protocol maturity.

I understand that the main focus of XMTP is to prevent censorship, by your own server, but this really a situation that can be mitigated efficiently with XMPP. You can for example run your own server or develop a fully decentralized approach, that you can leverage as needed (e.g. xmpp-overlay ).

Yes, there is still work to be done. For example, integrating MLS (Messaging Layer Security) into XMPP would provide a strong foundation for interoperable, end-to-end encrypted group messaging. But that only reinforces the point: Why ignore what’s already working and extensible?

Use What Works

New ideas are always welcome. Innovation matters. But messaging protocols are infrastructure. Reinventing them lightly, is not harmless, especially when it is done without acknowledging existing efforts.

Instead of multiplying disconnected stacks, we should double down on what works .

XMPP is here. It works. It evolves. It can be extended, adapted, and integrated, even into blockchain-native systems, without sacrificing openness or interoperability.

That may be its most valuable trait today: Still standing, while so many overengineered protocols have come and gone.