Aurora: a new identity for Fluux

Fluux has a new face. The app icon, logo, and the entire interface have been redesigned around Aurora, a teal-to-violet gradient identity with display headings, softer avatar shapes, and frosted-glass modals.

Aurora is more than a color swap:

• Per-person sender colors. Each participant in a group chat gets a stable, readable color, tuned for WCAG AA contrast in both light and dark themes.
• Curated accent presets. Pick the accent that suits you; the whole interface follows, including the encryption affordances, which now use one consistent color from the chat header to the message locks and the composer.
• Calmer chrome. Thinner scrollbars, consistent focus rings, quieter notification badges. Unread indicators now follow a simple two-tier model: red means something needs you (a direct message, a mention, a contact request), grey means ambient room activity.

If you preferred the previous color scheme, it is still there as the “Indigo classic” theme.

Conversation-first navigation

We removed the standalone Events view. It was a place you had to remember to check; now events come to you, in context:

• Contact requests, room invitations, and message requests appear as headed sections at the top of the relevant lists.
• A message from someone not in your roster opens as a read-only preview with an Accept / Ignore / Block banner, so you can see what it is before you commit to anything.
• Contacts moved down to the navigation cluster, with a badge when requests are pending.
• Archived conversations are one toggle away in the Messages header, and archiving now syncs live across your devices.

The result is fewer top-level destinations and less bookkeeping.

Jump anywhere with the command palette

Press Cmd-K (Ctrl-K on Windows and Linux) to jump to any conversation or action. The palette puts your unread chats and mentioned rooms first, shows avatars and unread badges, and never proposes the conversation you are already reading.

Unlimited scroll-back

The fixed 1,000-message cap on conversation history is gone. History is now a sliding window: scroll back as far as you like, and messages load incrementally from the local cache and the server archive (MAM). Combined with message-list virtualization, now on by default, long conversations stay fast, and typing no longer reflows the message list on every keystroke.

While we were in there, we fixed a long tail of scroll issues: new messages reliably stick to the bottom on WebKit, returning to a conversation restores exactly where you were reading (even deep in history), and jumping to a search result lands the message a third of the way down the viewport instead of hiding it under the date header.

Your reading position follows you

Read markers now sync across devices (XEP-0490). If you read a conversation on your desktop, it opens at the right position on your laptop, and its notification is dismissed. Together with live archive sync and the carbons and MAM work from previous releases, your devices now agree on what you have read, what is pending, and what is filed away.

A friendlier admin console

For those who administer their own ejabberd server, the ad-hoc command list is gone, replaced by purpose-built screens: a server overview dashboard, a searchable user list with online status and last login, a redesigned user detail view with a Ban account action, and a mobile launchpad. Only a few server admin commands are available so far, but we plan to grow the list with each new version.

Desktop and everyday polish

• Window app bar. The desktop app gets back/forward navigation in a proper window bar, with correctly centered traffic lights on macOS.
• Calm updates. Instead of reloading the app under your feet, a new “Update available” button appears in the icon rail when a new version is ready. You decide when.
• Reduce motion. A new accessibility setting minimizes animations and follows your system preference.
• Advanced mode. The XMPP console and expert settings are now behind an in-app toggle, keeping the default settings approachable.
• Redesigned contact details. A person-forward view with cards for devices, groups, and security, and fingerprint verification in its own focused panel.

And the usual pile of fixes

Almost 300 commits went into this release, so the full list is long. Some favorites: your own encrypted messages now show their real trust level instead of a grey lock under some circumstances; whispers in group chats keep their corrections and reactions private; animated avatars are frozen so they stop competing for your attention, even if they are PNGs; reactions from ignored users are hidden; and rooms are sorted correctly the moment the app launches.

The complete list is in the changelog .

Try it

Fluux Messenger 0.17.0 is available for macOS, Windows, and Linux, or directly in your browser. As always, it works with any standards-compliant XMPP server, and it remains our day-to-day client at ProcessOne.

If you upgrade and something feels off, tell us. A lot of what shipped in this release started as a user report.

0.16.1 is our quick turnaround on that: a focused round offixes for the issues that have been reported, across encryption, connectivity,message history, and the desktop apps. Nothing dramatic here, we mainly want to show that we&aposre listening and addressing reported problems fast.

End-to-end encryption in daily use

With people now encrypting real conversations, a few practical details surfaced —and they&aposre sorted:

• Verification works across clients. Fingerprints are published and compared in a consistent case (XEP-0373 expects upper-case), so the green "verified" lock appears reliably whatever XMPP client your contact uses.
• Cleaner previews and placeholders. Encrypted reactions now show up properly in the conversation list, and you&aposll see a "decrypting…" placeholder while the encryption plugin finishes loading.
• Complete archive. Encrypted messages without a plaintext body now come through correctly from server history (MAM).

Smoother connections

Field reports pointed to a handful of connection scenarios, now improved:

• Happy Eyeballs. Fluux races IPv4 and IPv6 when connecting, so a slow or broken IPv6 route no longer holds things up, whichever answers first wins.
• More reliable reconnection. Stream Management handling and the desktop&aposs local proxy hop were both tuned to resolve reconnection cases users reported.
• Clearer status. Presence pills stay grey while reconnecting, and the reconnect spinner and countdown are back in the sidebar status chip for a calmer interface on unstable networks.

More complete message history

• Gap recovery. Some users reported missing stretches of history after long periods offline. Catch-up now closes those gaps in both group chats and 1:1 conversations, with a "load missing messages" marker to bring back anything that was skipped.
• Reliable scroll-up. Loading older history by scrolling up now works as expected.

A more polished desktop experience

• Notifications open the right chat. On macOS, clicking a notification takes you straight to the conversation it belongs to.
• Single window. Relaunching the app focuses the window that&aposs already running instead of opening a second copy.
• Linux tray fallback. When the system tray isn&apost available, closing the window quits the app, so it can always be reopened.
• Image downloads use the native save dialog, and Settings now links straight to your system notification settings.

Lots of smaller fixes

And plenty of smaller refinements from everyday use: consistent empty-state icons, reply quotes that match the original sender&aposs color and render as nested bars, opening a contact profile no longer bouncing you back, link-preview images that retry once before hiding, a smoother composer resize, local JID validation on the login screen, and group-chat performance improvements on room join.

Thanks to everyone who reported issues and shared feedback – that&aposs exactly what shapes a release like this one. 0.16.1 is available now on our website , and the full changelog is on GitHub . Keep the reports coming!

Over the past few months, our team has been exploring what happens when systems come under pressure.

Through a series of webinars, we’ve looked at everything from concurrency in the BEAM to traffic spikes, real-time communication platforms, and resilient system design.

Maybe you’ve been following along, or maybe one or two of these webinars slipped past you. Either way, this is a chance to catch up on the ideas shaping how modern platforms are built and scaled.

Concurrency, Understanding the BEAM Limits

Modern systems can handle huge amounts of concurrent work. But sooner or later, every system reaches a point where performance starts to suffer.

In “Concurrency, Understanding the BEAM Limits”, Lorena Mireles Rivero explores how concurrency works inside the BEAM and where those limits begin to appear. Using examples from web applications and e-commerce platforms, she looks at how schedulers, mailboxes, CPU usage, and latency behave under load.

The session also explores common signs of system saturation and practical ways to keep applications running smoothly as demand grows.

Watch the webinar to learn more about concurrency in the BEAM and how to build systems that perform under pressure.

Keeping Real-Time Communication Platforms Online During Peak Demand

Real-time platforms don’t get a second chance. When demand spikes, messages still need to be delivered instantly and reliably.

In this webinar, Bartłomiej Górny explores what happens when systems are pushed to their limits. He looks at common bottlenecks, overloaded services, and how failures can spread across a platform when demand suddenly increases.

The session also covers practical approaches to scaling real-time systems, from service decoupling and back pressure to monitoring and load testing.

Watch the webinar to learn how real-time platforms can stay reliable during periods of peak demand.

How to Build Systems That Stay Online When Everything Spikes

Traffic doesn’t always increase gradually. Sometimes it arrives all at once.

In this session, Camjar Djoweini explores what happens when systems come under sudden pressure and why failures can quickly spread across services. He looks at where problems typically start and what makes some architectures more resilient than others.

The webinar focuses on designing systems that can absorb spikes, tolerate failures, and continue operating when conditions become unpredictable.

Explore the webinar to learn more about building resilient systems that stay online under pressure.

How to Build Platforms That Don’t Let Audiences Down

For gaming, betting, and entertainment platforms, traffic spikes are part of everyday life. The challenge is making sure users never notice them.

In this webinar, Lee Sigauke explores why systems fail during sudden surges in demand and how teams can build platforms that remain reliable under pressure. Drawing on principles from transactional systems in Erlang and Elixir, she shows how concurrency-first design helps systems cope with unpredictable workloads.

The session covers common failure patterns, resilience at scale, and practical ways to build platforms that continue performing when demand reaches its peak.

Watch the webinar to see how concurrency-first design helps platforms remain reliable when traffic surges.

To conclude

That wraps up our latest webinar round-up. We hope this guide helps you catch up on some of the ideas we’ve been exploring over the past few months.

If something here has sparked your interest, whether it’s concurrency in the BEAM, building resilient architectures, or keeping platforms reliable during periods of peak demand, we’d love to continue the conversation. So get in touch.

Here’s to building systems that stay stable, scalable, and ready for whatever comes next.

The post Erlang Solutions Webinar Round-Up appeared first on Erlang Solutions .

Here is a new version for slixmpp, the python XMPP library.

This release has one specific breaking change and two new XEP plugins. Thanks to everyone involved!

We are pleased to announce a new minor release from our stable branch.

This release fixes a handful of bugs which were discovered and fixed since the 13.0.5 release. Most of these are minor, but a few of them are important fixes.

A summary of changes in this release:

Fixes and improvements

• mod_cloud_notify: Use correct stanza id when clearing table entries (mem leak)
• mod_admin_shell: Don’t echo new password back to the client
• util.pubsub: Remove JIDs not permitted to be subscribed on affiliation change (fixes #1709 )

Minor changes

• mod_account_activity: Don’t traceback when called without options
• util.jsonschema: Always accept 0 for multipleOf properties
• util.paths: Fix check for adding installer path to package.cpath
• util.datamanager: Fix listing of host stores
• util.crypto: Use post-Lua 5.1 buffer API for improved memory safety
• util.dataforms: Don’t treat invalid jid-multi fields as missing
• util.crypto: Ensure signing parameter is a string
• util.poll: Reject unsupported file descriptors when using select() backend
• util.pubsub: Ensure deleted node stays in memory store deletion failed
• util.ringbuffer: Fix incorrect returned position from :find() for #needle~=1
• util.pposix: Fix incorrect syslog facility mapping
• util.ringbuffer: find(): Fix find logic bugs
• util.signal: Fix signalfd closure on non-Linux systems
• net.websocket: Fix traceback in client if server doesn’t respond with Connection header
• net.server_event: Fix incorrect flag logic for watchfd handles
• mod_debug_stanzas: Only clear active_filters when there are no subscribers
• mod_carbons: Fix ‘to’ attribute of stanzas to own account
• net.stun: Fix parsing of STUN packets with 0-length attributes
• mod_storage_memory: Fix assignment to ‘with’ when calling archive:set()
• net.http.parser: Include final component in path normalization check
• mod_register_ibr: Use set_password() instead of create_user() for resets
• mod_vcard: Ignore invalid photo data
• util.timer: Fix incorrect rescheduling of some kinds of timers

Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

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.

This new release has mostly internal improvements, but a few improvements and fixes as well.

Thanks to all contributors and users!

% git diff --stat v0.17...v0.18
…
157 files changed, 5366 insertions(+), 3158 deletions(-)

As we’re preparing the upcoming Openfire 5.1.0 release, I’ve been spending a lot of time looking at parts of the codebase that have been around for a long time.

Some of them date back to assumptions that were perfectly reasonable when Java 5 was current, IPv6 was still considered “future tech”, Docker didn’t exist yet, and “cloud-native” wasn’t a phrase anyone but meteorologists used.

Yet somehow, Openfire deployments that started in those days are still running today .

That got me wondering:

What’s the oldest Openfire deployment that you still run?

Not necessarily the oldest version (although I’d love to hear that too), but the oldest continuously running installation, the oldest surviving user database, or perhaps the weirdest setup that somehow still works despite years of upgrades, migrations and changing infrastructure.

I suspect there are Openfire instances out there that have survived datacenter migrations, moved from physical hardware to virtual machines to containers, switched databases more than once, and outlived several generations of administrators. Some probably still contain configuration decisions that nobody fully understands anymore. Is anyone still running Wildfire? Jive Messenger ?

Honestly, I love those stories from the trenches. The odd workarounds, the “temporary” fixes that became permanent infrastructure, the upgrade that everyone expected to fail but somehow didn’t, or the deployment that quietly kept running for a decade without anyone thinking much about it.

One of the things I appreciate most about infrastructure software is that success often becomes invisible. If a messaging server quietly keeps working for ten years, nobody talks about it. But that kind of stability is actually a huge achievement (both for the software and for the people operating it). I think that’s something we, as a community, can be genuinely proud of.

For Openfire 5.1.0, we’ve been modernizing quite a few internals:

• support for Java 25
• upgrades to Netty 4.2 and various database drivers
• improvements around reverse proxies and DNS handling
• clustering improvements
• security hardening
• performance fixes for larger deployments.

While doing that work, we constantly try to balance modernization with compatibility for long-running installations. That balancing act becomes much easier when we understand how people actually deploy and operate Openfire in the real world, which, apart from simply wanting to hear your stories, is another reason for me to ask this question.

So: I’d love to hear your stories! How old is your deployment? What version did you start with? What infrastructure changes has it survived over the years? Are there plugins or integrations you absolutely depend on? What operational lessons have you learned?

And perhaps most importantly: what surprised you most about running Openfire long-term?

I’m hoping this thread becomes a collection of deployment stories, operational lessons, and perhaps a bit of Openfire history.

Looking forward to hearing your stories!

We’d love to hear from you! Please join our community forum or group chat and let us know what you think!

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

1 post - 1 participant

Read full topic

Here is a new version for slixmpp, the python XMPP library.

Thanks to everyone involved for this release!

We are pleased to announce a new minor release from our stable branch.

This is a security release for the Prosody 13.0.x stable series. It fixes multiple security issues, some memory leaks and some smaller bugs and changes which have been implemented since the previous release.

Full details about the security vulnerabilities can be found in our security advisory . We encourage all Prosody operators on 13.0.4 or earlier to upgrade to 13.0.5 as soon as possible, or to review the advisory and implement appropriate mitigations.

A summary of changes in this release:

Security

• mod_proxy65: Consistently apply authorization checks
• mod_proxy65: Don’t proxy data until after bytestream activation
• mod_c2s, mod_s2s: Introduce new pre-authentication stanza size limit
• Add limit for stanza max child elements
• mod_c2s: Remove timers immediately on disconnection
• net.server_epoll: Clean up timers after disconnection

Fixes and improvements

• net.http.parser: Fix handling of chunked request
• MUC: Advertise hats feature on room JID (thanks Daniel)
• moduleapi: Use multitable add/remove instead of set (fixes memory leak)
• mod_cloud_notify: Fix leaking iq response handlers by using send_iq()
• Improve federation with servers using only IP addresses
• prosody: Prevent loading local code when installed system-wide
• mod_http_file_share: Improve handling of Range requests
• mod_carbons: Fix some carbons decision-making bugs (fixes #1861 : mod_carbons does not forward “sent” MUC PMs to other clients)

Minor changes

• net.resolvers: Fix to avoid SRV lookups for IP addresses
• prosody: Abort earlier on incompatible Lua version
• mod_turn_external: hand out credentials for type == turns too
• mod_s2s: Fully validate stream addressing
• prosodyctl check features: Warn if http file sharing enabled on both host and component
• util.prosodyctl: Don’t check for mod_posix being disabled, it’s deprecated
• util.startup: Improve error message when failing to load config file
• util.x509: Add support for iPAddress certs
• prosodyctl: Trim any trailing newline from password entry
• mod_admin_shell: Make cert index search path relative to config file
• mod_admin_shell: Improve multi-host command handling
• mod_admin_shell: Show help listing when specifying only a section name
• mod_admin_shell: Ensure password validity when setting passwords for new/existing users
• mod_account_activity: Handle authentication provider returning no user info
• config: Use default value when enum option has incorrect value
• mod_http: “Handle” streaming requests to avoid invoking redirect handler

Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!