Pl chevron_right

ProcessOne: Fluux Messenger 0.15.2: RTL Support, Faster Reconnection, and a Pile of Reliability Fixes

news.movim.eu / PlanetJabber • 21 hours ago • 3 minutes

Fluux Messenger 0.15.2: RTL Support, Faster Reconnection, and a Pile of Reliability Fixes

This is a maintenance release with a few notable additions: RTL language support, faster reconnection after stream-management resume, and a handful of reliability fixes scattered across reconnect edge cases.

RTL layout support (Arabic and Hebrew) and User interface tweaks

Fluux Messenger now renders correctly in right-to-left languages. Arabic and Hebrew translations are included in this release. Both are beta quality, so if you spot translation errors or layout glitches, please open an issue. Getting community feedback early is the fastest way to improve coverage.

On the UI side, blockquotes now use decorative quotation marks, a small polish detail that also helps in RTL contexts where quote direction matters.

Reconnection: faster and far more reliable

A significant chunk of this release is dedicated to making reconnects work the way they should. If you&aposve seen Fluux Messenger freeze after waking your laptop, or loop on reconnect attempts, most of those scenarios are addressed here.

Faster resume: When stream management successfully resumes a session, the client now skips redundant MAM queries. If the stream was cleanly resumed, there&aposs no need to re-fetch history, so reconnection feels almost instant in good network conditions.

Sleep/wake handling: Two separate bugs could cause the app to stall after a system sleep. One was a Tauri-specific reconnect stall, now recovered via native keepalive with a proxy fallback. The other was a post-wake auto-connect stall that happened after SASL negotiation completed but before the session was fully established. Both are fixed.

Loop prevention:

The reconnect attempt counter was incorrectly capped at the backoff ceiling, meaning it would stop growing and could trigger premature reconnect loops. That&aposs fixed, and superseded connection attempts now get a dedicated error class so they&aposre handled cleanly rather than causing UI freezes.

MUC room state: Room state is now properly preserved across stream-management resume and interrupted fresh sessions. Previously, a reconnect could wipe stored room messages or fail to restore saved rooms, leaving history empty after resume. Both are fixed: live room messages are written directly to IndexedDB, and rooms are restored through the connect call so history loads correctly after SM resume.

SASL2 and FAST token improvements

Several fixes land around SASL2 and FAST token handling:

The websocket stream from attribute is now correctly set, which is required for SASL2 to be accepted on compliant servers.
FAST token rotation now works correctly across page-reload reconnects.
Token authentication is retried when the server field was initially empty on login.
A spurious "FAST token deleted" log message that appeared on first login (when no token existed yet) is suppressed.
The SASL2 user-agent identifier is updated, and server-side FAST token invalidation is triggered on logout.
The outbound stream-management state is now hydrated on resume, preventing an ackQueue crash that could occur in certain reconnect scenarios.

Performance: per-conversation subscriptions

Typing indicators and draft state now use per-conversation subscriptions rather than a single global subscription. This reduces re-renders in the conversation list during background sync, which was noticeable when many conversations were active simultaneously. The list stays responsive while the client is catching up on missed messages.

Other fixes worth noting

Notifications: On web, notifications now use ServiceWorker.showNotification() for reliable delivery, replacing the previous approach that could silently fail.
Image lightbox: The lightbox no longer upscales images past their natural resolution, displaying the full-resolution original at actual size.
Web image cache: If the cache fetch fails, the client now falls back to loading directly from the URL instead of showing nothing.
Upload errors: HTTP upload errors are now displayed in the UI rather than failing silently. HTTP upload URLs are also now allowed.
Dynamic import failures: On failure, the client probes the runtime before reloading, and auto-reloads if the probe succeeds, skipping unnecessary hard reloads.
Discovery calls: Service discovery calls now run before the serial session-setup chain, which can shave time off the initial connection in some server configurations.
Accessibility: The scroll-to-bottom FAB now uses inert instead of aria-hidden , and the message toolbar "more" menu button vertical alignment is fixed.

Getting 0.15.2

The latest release is available on our website. The full changelog is in CHANGELOG.md on Github.

If you run into issues, especially around the new RTL translations or any of the reconnect scenarios, please open an issue. This release fixes a lot of edge cases and we want to make sure nothing slipped through.

Pl chevron_right

ProcessOne: ejabberd 26.04

news.movim.eu / PlanetJabber • 2 days ago • 2 minutes

Contents:

New limits options for XML parser

This release adds new options that limit max memory used by XML parser used to process XMPP payloads, to prevent potential Denial of Service attack. The default values for pre-auth provide sufficient protection for ejabberd against non-authenticated users on c2s and s2s, so there is no need to change your configuration.

The option max_stanza_elements sets a limit on the maximum number of XML elements that an individual stanza can contain. By default, this option is set to infinity .

The pair of options pre_auth_max_stanza_elements and pre_auth_max_stanza_size define separate limits for sessions that haven&apost authenticated yet. The session will switch to the limits defined by the options max_stanza_elements and max_stanza_size after the client has successfully authenticated. The default values for these options are: 32 for pre_auth_max_stanza_elements and 8192 for pre_auth_max_stanza_size .

All those options are recognized inside listener sections, and can be applied to ejabberd_c2s and ejabberd_s2s_in listeners.

ChangeLog

Core

Add new listener options to limit xml parser accepted input
Improve leave_cluster command to work even in own node
New predefined keyword DATABASE_PATH that points to the Mnesia spool dir
Support HOST keyword in sql_database toplevel option, set nice default value
Provide more details in log messages when using SQLite
Update documentation of jwt_key to match the Docs site
ejabberd_config: New default_ram_db/3 clause that checks module support
ejabberd_sm: Remove session_counter, used for get_vh_session_number now removed

Modules

mod_http_fileserver : Use integer in ejabberd_hooks:add as expected by "make hooks"
mod_invites : Add --enable-bootstrap=no to configure options to bypass download ( #4558 )
mod_invites : don&apost crash in get_invite_by_invitee_t for sql backend ( #4566 )
mod_invites : quick howto for creating integrity check checksums
mod_invites : remove dependency on jquery
mod_mqtt : Define RAM callbacks as optional
mod_mqtt : Use default_ram_db only if it really supports RAM storage
mod_roster : Fix bug introduced in 26.03 in commit d5c1440 ( #4564 )
mod_roster_sql : Cast approved integer as boolean when exporting Mnesia to SQL
mod_shared_roster_sql : Fix typo introduced 10 years ago in commit 0ea0ba30

Container and Installers

Bump Erlang/OTP 28.4.2
make-binaries: Bump OpenSSL to 3.5.6

Full Changelog

https://github.com/processone/ejabberd/compare/26.03...26.04

Acknowledgments

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

Stefan Strigler for the improvements in mod_invites

And also to all the people contributing in the ejabberd chatroom, issue tracker...

ejabberd 26.04 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub .

The source package and installers are available in ejabberd Downloads page. To check the *.asc signature files, see How to verify ProcessOne downloads integrity .

For convenience, there are alternative download locations like the ejabberd DEB/RPM Packages Repository and the GitHub Release / Tags .

The ecs container image is available in docker.io/ejabberd/ecs and ghcr.io/processone/ecs . The alternative ejabberd container image is available in ghcr.io/processone/ejabberd .

If you consider that you&aposve found a bug, please search or fill a bug report on GitHub Issues .

Pl chevron_right

JMP: Full Text Search with IndexedDB

news.movim.eu / PlanetJabber • 8 April 2026 • 5 minutes

While working on Borogove there has been a desire to have full-text search of locally-stored chat message history. For web-based apps the main storage engine in use is IndexedDB , which is a rather low-level system and certainly doesn’t have easy facilities for this kind of operation. So what’s the simplest, performant way to implement a full-text search on IndexedDB?

In case you are wondering “ what is full-text search ?” for our purposes we are going to be looking at a search where we want to find any message that contains all the words the user has typed, in any order

Table Scan

While this won’t be our final solution, it is almost always the right place to start. If your data is small (say, under 10k documents) then a table scan is pretty quick, and definitely the simplest option

// Helper so we can use promises with IndexedDB
function promisifyRequest(request) {
	return new Promise((resolve, reject) => {
	  request.oncomplete = request.onsuccess = () => resolve(request.result);
	  request.onabort = request.onerror = () => reject(request.error);
	});
}

const stopwords = ["and", "if", "but"];
function tokenize(s) {
	return s.toLowerCase().split(/\s*\b/)
		.filter(w => w.length > 1 && w.match(/\w/) && !stopwords.includes(w));
}

function stemmer(s) {
	// Optional, https://www.npmjs.com/package/porter2 or similar
}

async function search(q) {
	const qTerms = new Set(tokenize(q).map(stemmer));
	const tx = db.transaction(["messages"], "readonly");
	const store = tx.objectStore("messages");
	const cursor = store.openCursor();

	const result = [];
	while (true) {
        const cresult = await promisifyRequest(cursor);
        if (!cresult?.value) break;

		if (new Set(tokenize(cresult.value.text).map(stemmer)).isSupersetOf(qTerms) {
			result.push(cresult.value);
		}
		cresult.continue();
	}

	return result;
}

Even though we aren’t doing anything fancy with the database yet, there are still a lot of important building blocks here

First we tokenize the query. This means to chunk it up into “words”. Words don’t have to be exactly real words, they can be consistent parts of words or anything else, so long as you tokenize your query and document text in the same way. Here we use a simple strategy where we trust the \b word-break regex pattern, strip any extra whitespace, ignore any empty words or words made of only non-word characters (again, as determined by \w , nothing fancy), and also ignore any stopwords. A “stopword” is a very common word that is not useful to include in the search query such as “and”. Mostly, stopwords are useful to avoid blowing up the index size later, but we include it here for now for consistency

Next we stem the tokens. This is optional and depends on the kind of search you’re trying to build. The purpose of a stemmer is to make searches for eg “flying” also match messages containing the word “fly”

Then we iterate over all the items in the object store. If you wanted the results in a particular order, you could instead iterate over an index on the store in a particular order. We tokenize and stem the text from each item and check if it contains all the “words” from qTerms, if so it is part of the results.

Use an Index

Now what if you have many messages (one million or more, perhaps) and the simple table scan is just too slow. How can we speed this up? With IndexedDB we only get one kind of index: an ordered index, usually build on a B-Tree . This is not exactly what many full-text indexes are built on, but still we can get a very big performance boost without too much more complexity.

First in the onupgradeneeded migrator we need to create the index:

tx.objectStore("messages").createIndex("terms", "terms", { multiEntry: true });

This is a “multiEntry” index which means that the index will get one entry for each item in the array stored at this key, rather than indexing on the array as a whole piece. So when we store a new message we need to include the terms as an array:

tx.objectStore("messages").put({ text, terms: [...new Set(tokenize(text).map(stemmer))] });

Now, this does not let us search by our full query, but rather only by one word. How does this help us? Well, we can iterate over only documents which match at least one of the terms in our query. Which one should we pick? Counting items is pretty fast, so let’s pick whichever one has the smallest number of results:

async function search(q) {
	const qTerms = new Set(tokenize(q).map(stemmer));
	const tx = db.transaction(["messages"], "readonly");
	const store = tx.objectStore("messages");
	const index = store.index("terms");
	// Figure out which search term matches the fewest messages
	let probeTerm = null;
	let probeScore = null;
	for (const term of qTerms) {
		const score = await promisifyRequest(index.count(IDBKeyRange.only(term)));
		if (!probeTerm || score < probeScore) {
			probeTerm = term;
			probeScore = score;
		}
	}
	// Using the smallest list of messages that match one term
	// Find the ones that match every term
	const result = [];
	const cursor = index.openCursor(IDBKeyRange.only(probeTerm));
	while (true) {
		const cresult = await promisifyRequest(cursor);
		if (!cresult?.value) break;
		if (new Set(cresult.value.terms).isSupersetOf(qTerms)) {
			result.push(cresult.value);
		}
		cresult.continue();
	}

	// Sort results
	return result.sort((a, b) => a.timestamp < b.timestamp ? -1 : (a.timestamp > b.timestamp ? 1 : 0));
}

The operation to count the index for each term is pretty fast, but if you found this prohibitive, you could also store these counts in their own keys and update them as you insert new messages. Once we know which is the smallest, we then do the same scan as before, but only over that much smaller subset. The tokenized and stemmed terms are stored so we can compare against those directly here rather than doing it again.

Now if we want it sorted we have to do it ourselves, just like a DB engine would with this kind of query where the order we want does not match the index order.

On a test set of one million messages, this simple index was enough to take the performance from unusable grinding to almost instant responses, since the number of messages in the smallest term is usually still well under 10k.

Pl chevron_right

Mathieu Pasquet: Poezio 0.16.1

news.movim.eu / PlanetJabber • 7 April 2026

Here is 0.16.1, a bugfix and cleanup release for poezio, with exactly one new feature as an improvement over an existing plugin.

Poezio is a terminal-based XMPP client which aims to replicate the feeling of terminal-based IRC clients such as irssi or weechat; to this end, poezio originally only supported multi-user chats and anonymous authentication.

Features

Handle redacted/moderated messages in /display_corrections as well

Fixes

A bug in occupant comparison introduced in 0.16, leading to inconsistent MUC state in some cases.
Several fixes to MAM syncing and history gaps in MUC, which should be more reliable (but not perfect yet).
Issues around MUC self-ping ( XEP-0410 ) where you could not ever leave a room if it was enabled.
A bug in the new tcp-reconnect plugin which would traceback when disconnected.
Loading issues with plugins defined in entrypoints, of which the most common is poezio-omemo .

Internal

Introduction of a harsher linting pipeline.
Plenty of typing and linting fixes.
Added poezio-omemo to the plugins list in pyproject, for easier installation.

Links

Pl chevron_right

Erlang Solutions: What Breaks First in Real-Time Messaging?

news.movim.eu / PlanetJabber • 7 April 2026 • 6 minutes

Real-time messaging sits at the centre of many modern digital products. From live chat and streaming reactions to betting platforms and collaborative tools, users expect communication to feel immediate and consistent.

When pressure builds, the system doesn’t typically collapse. It starts to drift. Messages arrive slightly late, ordering becomes inconsistent, and the platform feels less reliable. That drift is often the first signal that chat scalability is under strain.

Imagine a live sports final going into overtime. Millions of viewers react at once. Messages stack up, connections remain open, and activity intensifies. For a moment, everything appears stable. Then delivery slows. Reactions fall slightly out of sync. Some users refresh, unsure whether the delay is on their side or yours.

Those moments reveal whether the system was designed with fault tolerance in mind. If it was, the platform degrades predictably and recovers. If it wasn’t, small issues escalate quickly.

This article explores what breaks first in real-time messaging and how early architectural decisions determine whether users experience resilience or visible strain.

Real-Time Messaging in Live Products

Live products place real-time messaging under immediate scrutiny. On sports platforms, streaming services, online games, and live commerce sites, messaging is visible while it happens. When traffic spikes, performance issues are exposed immediately.

User expectations are already set. WhatsApp reports more than 2 billion monthly active users , shaping what instant communication feels like in practice. That expectation carries into every live experience, whether it is chat, reactions, or collaborative interaction.

Source: Statista

Live environments concentrate demand rather than distribute it evenly. Traffic clusters around specific moments. Concurrency can double within minutes, and those users remain connected while message volume increases sharply. That concentration exposes limits in chat scalability far more quickly than steady growth ever would.

The operational impact tends to follow a familiar pattern:

Live scenario	System pressure	Business impact
Sports final	Sudden surge in concurrent users	Latency becomes public
Product launch	Burst of new sessions	Onboarding friction
Viral stream moment	Rapid fan-out across channels	Inconsistent experience
Regional spike	Localised traffic surge	Infrastructure imbalance

For live platforms, volatility comes with the territory.

When delivery slows or behaviour becomes inconsistent, engagement drops first. Retention follows. Users rarely blame infrastructure. They blame the platform.

Designing for unpredictable load requires architecture that assumes spikes are normal and isolates failure when it occurs. If you operate a live platform, that discipline determines whether users experience seamless interaction or visible strain.

High Concurrency and Chat Scalability

In live environments, real-time messaging operates under sustained concurrency rather than occasional bursts. Users remain connected, they interact continuously, and activity compounds when shared moments occur.

High concurrency is not simply about having many users online. It involves managing thousands, sometimes millions, of persistent connections sending and receiving messages at the same time. Every open connection consumes resources, and messages may need to be delivered to large groups of active participants without delay.

This is where chat scalability really gets tested.

In steady conditions, most systems appear stable. When demand synchronises, message fan-out increases rapidly, routing paths multiply, and coordination overhead grows. Small inefficiencies that were invisible during testing begin to surface. Response times drift. Ordering becomes inconsistent. Queues expand before alerts signal a problem.

High concurrency does not introduce entirely new issues. It reveals architectural assumptions that only become visible at scale. Concurrency increases are predictable in live systems. The risk lies in whether the messaging layer can sustain that pressure without affecting user experience.

Messaging Architecture Limits

The pressure created by high concurrency does not stay abstract for long. It shows up in the messaging architecture .

When performance degrades under load, the root cause usually sits there. At scale, every message must be routed, processed, and delivered to the correct subscribers. In distributed systems, that requires coordination across servers, and coordination carries cost. Under sustained traffic, small inefficiencies compound quickly.

Routing layers can become bottlenecks when messages must propagate across multiple nodes. Queues expand when incoming traffic outpaces processing capacity. Latency increases as backlogs grow. If state drifts between nodes, messages may arrive late or appear out of sequence.

This is where the earlier discussion of chat scalability becomes tangible. It is not only about supporting more users. It is about how efficiently the architecture distributes load and maintains consistency when concurrency remains elevated.

These limits rarely appear during controlled testing with predictable traffic. They emerge under real usage, where concurrency is sustained and message patterns are uneven.

Well-designed systems account for this from the outset. They reduce coordination overhead, isolate failure domains, and scale horizontally without introducing fragility. When they do not, performance drift becomes visible long before a full outage occurs, and users feel the impact immediately.

Fault Tolerance and Scaling

If you operate a live platform, this is where design choices become visible.

Once architectural limits are exposed, the question is how your system behaves as demand continues to rise.

Scaling real-time messaging is about making sure that when components falter, the impact is contained. Distributed systems are built on a simple assumption: things break. You will see restarts, reroutes and unstable network conditions. But the real test is whether your architecture absorbs the shock or amplifies it.

Systems built with fault isolation in mind tend to recover locally. Load shifts across nodes. Individual components stabilise without affecting the wider service. Systems built around central coordination points are more vulnerable to ripple effects.

In practical terms, the difference shows up as:

Localised disruption rather than cascading instability
Brief slowdown instead of prolonged degradation
Controlled recovery rather than platform-wide interruption

These behaviours define whether users experience resilience or instability.

Fault tolerance determines how the system behaves when conditions are at their most demanding.

Real-Time Messaging in Entertainment

Entertainment platforms expose weaknesses in real-time messaging quickly because traffic converges rather than building steadily over time.

When a live event captures attention, users respond together. Demand rises sharply within a short window, and those users remain connected while interaction increases. The stress on the system comes not from gradual growth, but from concentrated activity.

Take the widespread Cloudflare outage in November 2025 . As a core infrastructure provider handling a significant share of global internet traffic, its disruption affected major platforms simultaneously. The issue was due to underlying infrastructure, but the impact was immediate and highly visible because so many users were active at once.

Live gaming environments operate under comparable traffic patterns by design. During competitive matches on FACEIT , large numbers of players remain connected while scores, rankings, and in-game events update continuously. Activity intensifies around key moments, increasing message throughput while persistent connections stay open.

Across these environments, the pattern is consistent. Users connect simultaneously, interact continuously, and expect immediate feedback. When performance begins to drift, the impact is shared rather than isolated.

A Note on Architecture

This is where architectural choices begin to matter.

Platforms that manage sustained concurrency and recover predictably under pressure tend to share certain structural characteristics. In messaging environments, MongooseIM is one example of infrastructure designed around those principles.

In practical terms, that means:

Supporting large numbers of persistent connections without central bottlenecks
Distributing load across nodes to reduce coordination overhead
Containing failure within defined boundaries rather than allowing it to cascade
Maintaining message consistency even when traffic intensifies

These design choices do not eliminate volatility. They determine how the system behaves when it does.

In live entertainment platforms, that distinction shapes whether pressure remains internal or becomes visible to users.

Conclusion

Real-time messaging raises expectations that are easy to meet under steady conditions and far harder to sustain when attention converges.

What breaks first is rarely availability. It is timing. It is the subtle drift in delivery and consistency that users notice before any dashboard signals a failure.

Live environments make that visible because traffic arrives together and interaction compounds quickly. Concurrency is not the exception. It is the operating model. Whether the experience holds depends on how the architecture distributes load and contains failure.

Designing for that reality early makes scaling more predictable and reduces the risk of visible strain later.If you are building or modernising a platform where real-time interaction matters, assess whether your messaging architecture is prepared for sustained concurrency. Get in touch to continue the conversation.

The post What Breaks First in Real-Time Messaging? appeared first on Erlang Solutions .

Pl chevron_right

ProcessOne: Fluux Messenger 0.15: Search, Themes, Polls, and a Whole Lot More

news.movim.eu / PlanetJabber • 7 April 2026 • 3 minutes

Fluux Messenger 0.15: Search, Themes, Polls, and a Whole Lot More

We have shipped Fluux Messenger 0.15, and it is packed with major advancements. After the excitement of the FOSDEM launch, the team put their heads down on three things users were asking for most: the ability to find past messages, a messenger that looks and feels different from Discord, and richer collaboration tools for group rooms.

Find anything, instantly

Full-text search is now built into Fluux Messenger, every conversation, every room, searchable, locally and instantly.

The search engine runs entirely on your device using an IndexedDB inverted index with prefix matching and highlighted result snippets. No messages leave your machine to power this. For rooms with deep history on the server, results are supplemented with MAM (Message Archive Management) server-side queries, giving you the best of both worlds: speed from local cache, completeness from the archive.

A find-in-page mode (Cmd+F) lets you scan within any conversation, mirroring the browser experience developers expect.

Make it yours: a full theme system

Fluux Messenger now ships with a proper design token system, three-tier (Foundation → Semantic → Component), and a theme picker bundled in the Appearance settings.

Twelve themes are available out of the box: Fluux, Dracula, Nord, Gruvbox, Catppuccin Mocha, Solarized, One Dark, Tokyo Night, Monokai, Rosé Pine, Kanagawa, and GitHub. If none of them are quite right, you can import your own theme or inject CSS snippets directly. A global accent color picker with theme-specific presets lets you go further without writing a single line of code.

Font size adjustment is now in Appearance settings as well.

Polls in group rooms

Reaction-based polls are now a first-class feature in MUC rooms. Create a poll with custom emojis, set a deadline, and let participants vote. The room enforces voting rules server-side, so results are trustworthy. Polls can be closed and reopened, and an "unanswered" banner nudges participants who haven&apost voted yet. Results are visualized inline and captured in the activity log.

Faster connections with FAST authentication

Fluux Messenger now supports XEP-0484: FAST (Fast Authentication Streamlining Tokens) alongside SASL2. Reconnection after a network interruption or wake from sleep is now possible in the web version.

Media cache

Downloaded images are now cached to the filesystem, so they load instantly on revisit and don&apost count against your bandwidth twice. A new storage management screen in settings lets you see and clear the cache.

Polish and fixes worth noting

Emoji picker (emoji-mart) with dynamic viewport positioning, so it never clips off-screen
Last Activity (XEP-0012) — offline contacts now show how long ago they were last seen
Syntax highlighting for code blocks, lazily loaded per language, with theme integration and a fullscreen modal for long snippets
IRC-style mention detection with consistent per-user colors (XEP-0392)
VCard popovers on occupant and member list nicks
Scroll-to-bottom button now shows an unread badge and implements two-step scroll: first click jumps to the new message marker, second click goes to the very bottom
Particle burst animation when adding a reaction, and a message send slide-up animation
Upgraded to React 19 with the React Compiler for automatic memoization, and Vite 8 with lazy-loaded views for a faster startup

A note on Windows signing

Starting with 0.15, the Windows binary is no longer signed. This is a temporary decision while we work through the signing infrastructure — full details are in issue #290 . On install, Windows will prompt you to manually trust the application. We know this isn&apost ideal and are working to restore signed builds.

Get it

Fluux Messenger 0.15 is available now. Download it here or check the full changelog on GitHub for every detail.

As always, feedback and bug reports are welcome. The community is the best part of building open-standard messaging software.

Pl chevron_right

Ignite Realtime Blog: Experimenting with MariaDB, Firebird and CockroachDB Support in Openfire

news.movim.eu / PlanetJabber • 6 April 2026 • 1 minute

I have recently started experimenting with adding support for three additional databases in Openfire: MariaDB, Firebird and CockroachDB.

This work is still exploratory. Before committing to this direction, I would like to get a better understanding of whether this is actually valuable to the Openfire community.

I have prepared initial pull requests for each database:

MariaDB: https://github.com/igniterealtime/Openfire/pull/3240 ( OF-3239 in our issue tracker)
Firebird: https://github.com/igniterealtime/Openfire/pull/3241 ( OF-3237 in our issue tracker)
CockroachDB: https://github.com/igniterealtime/Openfire/pull/3243 ( OF-3238 in our issue tracker)

These are not production-ready, but intended to validate feasibility and surface any obvious issues.

Why these databases?

MariaDB is widely used as a drop-in replacement for MySQL. Although Openfire supports MySQL, MariaDB is not explicitly treated as a first-class option. Given how often it is used in practice, formal support could provide more confidence for administrators.

Firebird represents a more niche but still relevant ecosystem. It is commonly found in long-lived, on-premise systems where changing the database is not realistic. Supporting it could make Openfire easier to adopt in those environments.

CockroachDB targets modern, distributed deployments. With its PostgreSQL compatibility and focus on resilience and scalability, it could make Openfire more attractive for cloud-native and multi-region setups.

Trade-offs

Supporting additional databases comes with a cost: more code paths, more testing, and more long-term maintenance. The key question is whether the added flexibility justifies that complexity.

Feedback wanted

Before taking this further, I would really appreciate feedback from the community:

Are you using (or considering) MariaDB, Firebird or CockroachDB with Openfire? Would official support influence your deployment decisions? Do you see this as valuable, or as unnecessary complexity?

Please share your thoughts on the pull requests or through the usual community channels!

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

1 post - 1 participant

Read full topic

Pl chevron_right

Erlang Solutions: Avoiding Platform Lock-In in Regulated Environments

news.movim.eu / PlanetJabber • 27 March 2026 • 6 minutes

Platform lock-in is often discussed as a commercial issue. Organisations adopt infrastructure that works well initially and later realise that moving away from those services becomes expensive or operationally disruptive.

For platforms that run continuously under heavy demand, the consequences appear somewhere else first. They appear in architecture.

Infrastructure choices influence how systems scale, how faults are contained, and how easily the platform can evolve as requirements change. In regulated environments those decisions often remain in place for years, which means architectural flexibility matters as much as technical capability.

When infrastructure becomes tightly coupled to a particular provider, systems may still perform well day to day. The real impact usually surfaces later when workloads grow, regulations change, or operational expectations increase. At that point platform lock-in risks begin to affect reliability as well as flexibility.

Why Platform Lock-in Matters in Regulated Environments

These architectural constraints become particularly visible in regulated industries where infrastructure decisions cannot be changed casually.

Financial services platforms must maintain traceable transactions and strict audit trails. Betting platforms process large volumes of activity during live sporting events. Streaming platforms deliver real-time content to global audiences who expect uninterrupted interaction.

Systems supporting these environments often remain active for long periods, which means infrastructure decisions made early in the system’s lifecycle can shape how the platform changes years later.

The Operational Impact of Vendor Lock-in

Many organisations already recognise the risks associated with vendor lock-in. The 2024 Flexera State of the Cloud Report found that 89% of organisations now operate multi-cloud strategies, with reducing infrastructure dependency and avoiding vendor concentration cited as key motivations.

The concern goes beyond procurement strategy. When platforms rely heavily on provider-specific services for messaging, orchestration, or event processing, those dependencies begin shaping how the system behaves under load.

In regulated environments that dependency can become a reliability concern. Infrastructure decisions that once simplified development may later restrict how systems scale, evolve, or respond to operational change.

Distributed Systems Architecture and Long-Running Platforms

The reason platform lock-in becomes particularly serious in regulated environments is tied to how many of these platforms operate: as long-running distributed systems.

Large-scale entertainment services rarely behave like short-lived workloads that restart frequently. Messaging layers, real-time interaction systems, and event pipelines maintain persistent connections while processing continuous streams of activity.

Why Long-Running Systems Behave Differently

Gaming platforms illustrate this clearly. Competitive environments host thousands of players interacting simultaneously, all of whom expect consistent state across the system. Betting platforms experience similar behaviour during major sporting events when users react instantly to changing odds. Streaming platforms see comparable spikes as audiences interact during live broadcasts.

These platforms rely on distributed systems architecture that must coordinate large numbers of connections and events while remaining continuously available.

Research published by ACM Queue examining large-scale distributed systems highlights how persistent connections and real-time workloads increase coordination pressure across system components, particularly during sudden spikes in concurrency.

When coordination layers rely heavily on platform-specific services, architectural dependency gradually builds. Over time the system begins to inherit those infrastructure constraints.

Reliability Requirements in High Reliability Systems

Systems operating under these conditions often prioritise stability over rapid iteration. Platforms designed as high reliability systems must remain available while managing constant traffic, evolving workloads, and unpredictable user behaviour.

Infrastructure decisions therefore have long-term consequences. When coordination, messaging, or state management rely on proprietary platform services, architectural flexibility narrows over time.

Why Gaming, Betting and Streaming Platforms Reveal Infrastructure Limits

Systems built as long-running distributed environments face their toughest tests during moments of concentrated demand. Entertainment platforms provide a clear example.

Large audiences often react simultaneously. A football match entering extra time can trigger thousands of betting transactions within seconds. A major esports tournament can bring large numbers of players online at once. Streaming platforms experience bursts of interaction as viewers respond together during live broadcasts.

Traffic Spikes and Scalable Distributed Systems

Systems supporting these environments must function as scalable distributed systems capable of handling sudden increases in activity without losing consistency or responsiveness.

Instead of steady growth, activity often arrives in waves. Large numbers of users connect, interact, and generate events within very short timeframes. The system must coordinate these interactions across multiple nodes while maintaining reliable communication between services.

Infrastructure that appears sufficient under normal conditions can struggle during these spikes if the surrounding architecture relies too heavily on provider-specific services.

Real-World Example: BET Software

These architectural pressures are particularly visible in betting platforms where activity surges during live sporting events.

BET Software operates large-scale betting technology platforms where thousands of users interact with markets simultaneously. During major sporting events systems must process rapid updates, recalculate market information, and distribute new data to users in real time.

BET Software: Avoiding platform lock-in in regulated environments

Their distributed systems illustrate how reliability and responsiveness become essential in environments where activity concentrates around shared moments.

Architectures designed with flexibility across infrastructure layers tend to scale and recover more predictably than those tightly coupled to provider-specific services.

Architectural Patterns to Avoid Vendor Lock-in

Recognising the risks of vendor lock-in is useful only if it leads to better architectural decisions. Systems that remain adaptable across infrastructure layers often share several structural characteristics.

Decoupling Infrastructure Dependencies

Architectures designed to avoid vendor lock-in typically separate application logic from infrastructure services wherever possible. This allows teams to evolve system components independently without redesigning the entire system,

Designing Fault Tolerant Systems

Platforms that must operate continuously also benefit from architectures designed as fault tolerant systems , where failures can be contained locally rather than cascading across the entire platform.

Common patterns include:

Decoupled services that scale independently
Communication through open protocols rather than proprietary messaging layers
Distributed state management instead of provider-specific coordination services
Horizontal scaling across nodes
Infrastructure abstraction layers separating application logic from provider-specific implementations
These approaches help ensure that infrastructure choices support the system rather than define its limitations.

These patterns help ensure that infrastructure choices support the system rather than define its limitations.

Where Elixir Supports High Reliability Systems

Technology choices also influence how easily distributed systems can maintain reliability while remaining adaptable.

Languages built on the Erlang virtual machine, including Elixir, were designed for environments where systems must remain available while handling large numbers of concurrent processes. The runtime emphasises process isolation and supervision structures that allow failures to be contained locally rather than cascading across the system.

Building Fault Tolerant Systems for Long-Running Platforms

These characteristics make the platform particularly well suited for high reliability systems that must remain active while managing heavy concurrency.

The advantage lies in the runtime model rather than any single infrastructure provider. Systems built around resilient distributed behaviour are easier to evolve because they remain stable even as infrastructure decisions change around them.

Designing Systems That Reduce Platform Lock-in

Looking across these examples reveals a consistent pattern.

Platform lock-in becomes most visible in systems that must operate continuously while adapting to changing demand. Regulated environments amplify the challenge because infrastructure decisions often remain in place for years while platforms continue to evolve.

Gaming, betting, and streaming services make these limits easier to see. Sudden spikes in activity quickly expose architectural weaknesses, and systems designed with flexible infrastructure tend to scale and recover more predictably.

If you are building platforms where reliability and long-running distributed workloads matter, it may be worth assessing how your architecture handles platform lock-in. To explore these challenges further, get in touch with the Erlang Solutions team.

The post Avoiding Platform Lock-In in Regulated Environments appeared first on Erlang Solutions .

Pl chevron_right

ProcessOne: ejabberd 26.03

news.movim.eu / PlanetJabber • 25 March 2026 • 4 minutes

If you are upgrading from a previous version, there is a change in the SQL schemas, please read below. There are no changes in configuration, API commands or hooks.

Contents:

Changes in SQL schemas
SASL channel binding changes
ChangeLog
Acknowledgments
Improvements in ejabberd Business Edition
ejabberd 26.03 download & feedback

Changes in SQL schema

This release adds a new column to the rosterusers table in the SQL database schemas to support roster pre-approval. This task is performed automatically by ejabberd by default.

However, if your configuration file has disabled update_sql_schema toplevel option, you must perform the SQL schema update manually yourself. Those instructions are valid for MySQL, PostgreSQL and SQLite, both default and new schemas:

ALTER TABLE rosterusers ADD COLUMN approved boolean NOT NULL AFTER subscription;

SASL channel binding changes

This version adds the ability to configure the handling of the client flag &aposwanted to use channel-bindings but was not offered one&apos . By default, ejabberd aborts connections that present this flag, as this could indicate the presence of a rogue MITM proxy between the server and the client that strips the exchanged data of information required for this.

This can cause problems for servers that use a proxy server which terminates the TLS connection (i.e. there is a MITM proxy, but it is approved by the server administrator). To handle this situation, we have added code to ignore this flag if the server administrator disables channel binding handling by disabling the -PLUS authentication mechanisms in the configuration file:

disable_sasl_mechanisms:
  - SCRAM-SHA-1-PLUS
  - SCRAM-SHA-256-PLUS
  - SCRAM-SHA-512-PLUS

We also ignore this flag for SASL2 connections if offered authentication methods filtered by available user passwords did disable all -PLUS mechanisms.