call_end

    • Pl chevron_right

      Erlang Solutions: ​​Expert Insights from Our Latest Webinars

      news.movim.eu / PlanetJabber • Yesterday - 10:21 • 2 minutes

    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.

    SAFE webinar

    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.

    Messaging in Regulated Markets webinar

    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.

    Gleam webinar

    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.

    'with' webinar

    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.

    Women in Elixir webinar

    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 .

    • Pl chevron_right

      XMPP Interop Testing: Putting NTA 7532 to the Test (Literally)

      news.movim.eu / PlanetJabber • 3 days ago - 19:40 • 3 minutes

    You might have seen the XMPP Standards Foundation’s open letter to NEN about NTA 7532 , the Dutch effort to standardise secure healthcare chat. It’s a good read, and, as it happens, right up our street.

    If you’re building a chat system that has to actually talk to someone else’s chat system (and keep doctors happy while doing it), you’ll know: writing a specification is only half the battle. The other half is making sure that everyone follow it, and that everyone follows it in the same way.

    That’s where the XMPP Interop Testing Framework comes in.

    So, What Do We Do Again?

    In short: we make sure XMPP software behaves the way the standards say it should.

    We’ve built an open-source test framework that runs a bunch of automated checks against real XMPP servers using a real XMPP client library, testing everything from the core RFCs (6120, 6121, 7622) to the popular protocol extensions for things like:

    • message receipts ( XEP-0184 )
    • group chat ( XEP-0045 )
    • file upload ( XEP-0363 )
    • end-to-end encryption

    It’s all designed to run in CI, with containers, and produce nice, clear pass/fail results, along with machine-consumable reports and human-readbale actionable information. The kind you can wave around in a meeting and say “See? Interoperable!”

    Why NTA 7532 Folks Should Care

    NTA 7532 is about making sure healthcare professionals can message each other securely, even when they’re on different systems and members of different organizations. That means encryption, integrity, and actual interoperability between products from different vendors.

    You could write those requirements into a 200-page document (and you probably will). But to prove it works, you need tests. Preferably ones that don’t take a week to run by hand, and that aren’t only run just prior to launch and never again.

    That’s exactly what we provide.

    Our framework already checks for the building blocks that NTA 7532 is likely to depend on: authentication, transport security, message delivery, receipts, and so on. And because the tests are open and automated, every vendor can run the same suite - no secret sauce or proprietary knowledge required.

    From “We Think” to “We Know”

    Here’s the value add:

    1. Validation - The framework tells you, with logs and evidence, whether a given implementation matches the spec or standard.
    2. Transparency - Everyone can see what’s tested and why and how. The same tests for everyone, with the same criteria.
    3. Continuous improvement - When specs change or new features appear, we add new tests. Easy.

    It turns a written standard into a living, testable thing . If you want to know whether two systems will work together before putting them in front of clinicians, this is how you find out.

    The Bigger Picture

    The fun part is collaboration.

    The XSF writes and maintains the XMPP specs. NEN and the folks behind NTA 7532 define the national healthcare chat profile. And we, the Interop Testing Framework team, provide the bit in the middle: the place where specs meet running code.

    Together, we can prove that “open standard” isn’t just a phrase, but that it’s something you can test, verify, and rely upon.

    What’s Next

    We’d love to:

    • run pilot tests with any NTA 7532-aligned vendors
    • map specific NTA 7532 requirements to existing (or new) XMPP test cases
    • publish anonymised results to show real-world interoperability
    • feed our findings back to both the NTA 7532 working group and to the XSF

    If that sounds like something you’d like to be part of: fantastic!

    Come talk to us.

    Get Involved

    The framework’s open-source, so dive right in:

    Whether you’re writing specs, building servers, or just trying to get two chat systems to agree on a message receipt, we’re here for you.

    Let’s make interoperability not just a checkbox, but a test you can actually pass ✅

    Splash image courtesy of Marcus Urbenz, Unsplash

    • Pl chevron_right

      ProcessOne: rocket ejabberd 25.10

      news.movim.eu / PlanetJabber • 3 days ago - 18:00 • 10 minutes

    🚀 ejabberd 25.10

    Release Highlights:

    If you are upgrading from a previous version, there are no mandatory changes in SQL schemas, configuration, API commands or hooks.

    Other contents:

    Below is a detailed breakdown of the improvements and enhancements:

    New option archive_muc_as_mucsub in mod_mam

    When this option is enabled incoming groupchat messages for users that have MucSub subscription to a room from which message originated will have those messages archived after being converted to mucsub event messages.

    Removed support for Erlang/OTP older than 25.0

    The ejabberd 24.12 release announcement explained that support for Erlang/OTP older than 25.0 was discouraged, it would be deprecated in future releases, and completely removed sometime after ejabberd 25.01. That explanation was mentioned several times in the subsequent ejabberd releases.

    The initial reason to require Erlang/OTP 25 was that this version is the lowest we can easily use nowadays for running the CI tests .

    Other reasons to remove support for Erlang lower than 25 are: to support maybe expression, and to remove duplicate code.

    In order to support both new and very old Erlang/OTP versions, ejabberd source code included many duplicate code. All that duplicate code that is nowadays useless will be removed in a future ejabberd release.

    Support for the new Erlang &aposmaybe&apos expression

    The new maybe expression is supported since Erlang/OTP 25 (requires being enabled), and it is enabled by default since 27.

    Now that ejabberd requires Erlang/OTP 25, and it enables the maybe expression, this can be used freely in ejabberd source code and modules.

    See:

    Rename &aposNew&apos SQL schema to &aposMultihost&apos, and &aposDefault&apos to &aposSinglehost&apos

    When ejabberd first got support for SQL storage, it only supported one vhost, so it made sense to not store the host in the SQL tables. Additionally, the SQL schema in ejabberd followed that of jabberd14, which didn&apost support multiple vhosts either.

    When ejabberd got support for multiple vhosts, if several of them want to use SQL storage, the solution is to configure a different SQL database for each vhost using the host_config toplevel option.

    However, when there are many vhosts configured in ejabberd, all of them using SQL storage, it is preferable to setup one single SQL database, and store the vhost in the tables. When that feature was added to ejabberd, it got the name of "new SQL schema". And the previous SQL schema was called "legacy", "old", and nowadays "default".

    The problem with the terms "default" and "new" is that they are circumstantial, and do not really describe the schema features or purposes.

    Now those terms have been renamed:

    • "default SQL schema" ⟹ "singlehost SQL schema"
    • "new SQL schema" ⟹ "multihost SQL schema"

    Right now all names are supported, the previous (obsolete) and the renamed (preferred). No changes are needed in your existing configuration file or building instructions, but it is preferable if you can update your setup to the new terms:

    When preparing configuration, the old and new arguments are:

    ./configure --enable-new-sql-schema
    ./configure --enable-multihost-sql-schema
    

    When configuring ejabberd, the old and new toplevel options are:

    new_sql_schema: true
    sql_schema_multihost: true
    

    When developing source code, the old and new functions are:

    ejabberd_sql:use_new_schema()
    ejabberd_sql:use_multihost_schema()
    

    New API Commands

    Several ejabberd modules implement new API Commands, most of them inspired by XEP-0133 :

    Added more Ad-Hoc Commands from XEP-0133

    XEP-0133 describes 31 administrative tasks that should be available as ad-hoc commands.

    ejabberd already implemented many of those ad-hoc commands in mod_configure , but there were a few missing that nowadays are fairly easy to implement: this new ejabberd release supports all of them... except 5.

    The five ad-hoc commands from XEP-0133 that are not supported are:

    • 6. Get User Password , because it was already retracted in the XEP and should not be implemented
    • 12. Edit Whitelist , because the corresponding feature is not implemented in ejabberd
    • 27. Set Welcome Message , because in ejabberd this message is set in the configuration file, option welcome_message of mod_register
    • 28. Delete Welcome Message , for similar reason
    • 29. Edit Admin List , because in ejabberd the administrative rights to accounts are granted in the configuration file, toplevel option acl .

    On the other hand, ejabberd implements more than 200 API commands in all over its source code, providing those and many other administrative tasks. And you can execute those API commands using the command line, ReST calls, XML-RPC, WebAdmin, ... and ad-hoc commands too!!! See the available API frontends .

    Nowadays, all the ad-hoc commands described in XEP-0133 have a similar API command in ejabberd that you can execute using ad-hoc commands too:

    Ad-hoc command in XEP-0133 Status in ejabberd 25.10 Equivalent API command
    Add User 〽️ (no vCard arguments) register
    Delete User unregister
    Disable User ban_account
    Re-Enable User unban_account
    End User Session 〽️ (argument) kick_session
    Get User Password (retracted) ▶️ (retracted) check_password
    Change User Password change_password
    Get User Roster 〽️ (result syntax) get_roster
    Get User Last Login Time get_last
    Get User Statistics user_sessions_info
    Edit Blacklist ▶️ add_blocked_domain
    Edit Whitelist -
    Get Number of Registered Users stats
    Get Number of Disabled Users count_banned
    Get Number of Online Users stats
    Get Number of Active Users status_num
    Get Number of Idle Users status_num
    Get List of Registered Users registered_users
    Get List of Disabled Users list_banned
    Get List of Online Users connected_users
    Get List of Active Users status_list
    Get List of Idle Users status_list
    Send Announcement to Online Users announce_send_online
    Set Message of the Day announce_motd_set_online
    Edit Message of the Day announce_motd_update
    Delete Message of the Day announce_motd_delete
    Set Welcome Message ▶️ (option welcome_message in mod_register )
    Delete Welcome Message ▶️ (option welcome_message in mod_register )
    Edit Admin List ▶️ (option acl )
    Restart Service restart_kindly
    Shut Down Service stop_kindly

    Status legend:

    • ✅ Implemented in ejabberd exactly as XEP-0133 describes it
    • 〽️ Implemented with same command name, but different arguments or results
    • ▶️ Not implemented as XEP-0133 says, but we have an alternative solution
    • ❌ Not implemented in ejabberd in any way

    Updated support for XEP-0317 Hats

    Support for XEP-0317 Hats is improved from 0.2.0 to the latest 0.3.1.

    Previously, the XEP lacked some use cases, and ejabberd implemented them as custom additional features, as documented in MUC Hats . Now that the XEP includes all those additions, ejabberd strictly follows XEP-0317 version 0.3.1.

    Improved GitHub Workflows

    The ejabberd git repository contains several GitHub Workflows to test automatically the source code with static and dynamic tools, build installers and containers.

    Those workflows recently got several improvements:

    • Run agnostic-database tests only once, not for every backend
    • Add local composite actions to manage ejabberd and databases
    • Reorganize steps in the CI workflow to run in parallel jobs
    • Use ARM runners to build ARM installers and containers, no need for cross compiling
    • Use ARM runners instead of x86 when possible, as they run faster
    • Cache dependencies and download from CDNs when possible

    With all those improvements, the workflows complete (or give some error report) in less than 10 minutes, instead of the 30 minutes that were common before.

    For details about those changes, check PR 4460

    Acknowledgments

    We would like to thank the contributions to the source code provided for this release by:

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

    Improvements in ejabberd Business Edition

    Customers of the ejabberd Business Edition , in addition to all those improvements and bugfixes, also get the following changes:

    • The bulk_roster_update API command now accept a list of groups.
    • The mod_dedup module has been improved to handle received markers. This module was added in 4.2508 to prevent both delivery and storage of duplicates in archive.
    • Fixed a case where a mobile client was not able to retrieve all the messages received while it was offline after a temporarily loses of its data connection.

    ChangeLog

    This is a more complete list of changes in this ejabberd release:

    Ad-hoc Commands

    • mod_configure : New ad-hoc commands that were missing from XEP-0133
    • mod_adhoc_api : Add support for asynchronous command calling
    • mod_adhoc_api : If argument is a list of jids, type is jid-multi
    • mod_adhoc_api : If field has several values, type is text-multi

    API Commands

    • Add commands argument type binary_or_list
    • mod_http_api : Format sub elements for tuples from maps
    • mod_admin_extra : Improve roster API commands documentation
    • mod_announce : New API commands, reusing existing ad-hoc functions
    • ejabberd_admin : New API command restart_kindly , improve stop_kindly
    • mod_admin_extra : New API commands list_banned and count_banned
    • mod_admin_extra : Improve API command status_list : support for status to be a list
    • mod_muc_admin : New API commands muc_get_registered_nick and nicks ( #4468 )
    • Use mod_private:del_data in unban_account API command

    Configuration

    • Rename New SQL schema to Multihost , and Default to Singlehost ( #4456 )
    • Add config transformer from use_new_schema -> sql_multihost_schema
    • mod_sip : Fix problem parsing via in yconf library ( #4444 )

    Erlang/OTP support

    • Enable feature maybe_expr in the compiler for Erlang/OTP 26 ( #4459 )
    • Enable feature maybe_expr also in the runtime for Erlang/OTP 25
    • Runtime: Remove Erlang 24 which won&apost work anymore with maybe_expr
    • Remove EX_RULE and EX_STACK macros only used with ancient erlang

    GitHub Workflows

    • CI: Bump XMPP-Interop-Testing/xmpp-interop-tests-action ( #4469 )
    • CI: Don&apost care to include commit details in the CT logs HTML page
    • CI and Runtime: Reorganize steps to run in parallel, and ARM runner ( #4460 )
    • Add local composite actions to manage ejabberd and databases
    • Container: Build ARM in native runner instead of QEMU, merge and clean
    • Installers: Generate ARM installers in native runner
    • Tests: Run agnostic-database tests only once, not for every backend
    • Tests: The odbc backend is not actually used in Commont Tests
    • Weekly: New workflow that condenses CI, test all erlang without caching

    Installers and Containers

    • Bump Erlang/OTP version to 27.3.4.3 in installers and container
    • Bump Expat 2.7.3, OpenSSL 3.5.4, unixODBC 2.3.14 in installers

    MUC

    • mod_mam : New option archive_muc_as_mucsub
    • mod_muc : Check if room is hibernated before calling mod_muc process
    • mod_muc : Update implementation of XEP-0317 Hats to version 0.3.1 ( #4380 )
    • mod_muc : Make mod_muc_sql properly handle new hats data ( #4380 )
    • mod_muc_room : Don&apost require password if user is owner of room
    • mod_muc_admin : Use in WebAdmin the new API commands that get nick registers

    Core and Modules

    • ejabberd_http_ws : Pass HTTP headers from WS to C2S connection ( #4471 )
    • ejabberd_listener : Properly pass send_timeout option to listener sockets
    • ejabberdctl : When ping returns pang, return also status code 1 ( #4327 )
    • ext_mod : Print module status message after installation
    • misc : json_encode should always call json with our filter
    • mod_admin_update_sql : Use same index name than when creating database
    • mod_block_strangers : Clarify access and captcha documentation ( #4221 )
    • mod_http_upload : Encode URL before parsing, as done before bba1a1e3c ( #4450 )
    • mod_private : Add del_data/3 , get_users_with_data/2 , count_users_with_data/2
    • mod_pubsub : Don&apost catch exit:{aborted, _} inside mnesia transactions
    • mod_push : Run new hook push_send_notification ( #4383 )
    • WebAdmin: Respect newline and whitespace characters in results

    Full Changelog

    https://github.com/processone/ejabberd/compare/25.08...25.10

    ejabberd 25.10 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

      Ignite Realtime Blog: Helping Dutch Healthcare Speak the Same Language with XMPP

      news.movim.eu / PlanetJabber • 3 days ago - 09:14 • 2 minutes

    Helping Dutch Healthcare Speak the Same Language with XMPP

    The XMPP Standards Foundation (XSF) has put out a call to action : it’s time for the community to help make secure, interoperable chat a reality - especially in healthcare. Here at Ignite Realtime, we’re excited to support this effort. Our projects, such as Openfire and Smack , provide powerful building blocks to explore what’s possible for Dutch healthcare communication.

    Building Blocks for Dutch Healthcare Messaging

    Many of the features mentioned in the XSF’s call to action (such as attachments, group chat, and read receipts) are already available in our projects, providing a strong foundation for exploring messaging workflows. Openfire offers a scalable XMPP server with a flexible plugin system, while Smack , a modular Java library for building clients on Android, desktop, or other platforms, makes it possible to experiment with custom client-side solutions. Together, these tools allow developers and organizations to prototype, test, and explore how messaging could work in Dutch healthcare contexts.

    How Our Community Can Contribute

    Even though the Dutch healthcare chat standard is still being finalized, there are ways to explore and prepare for it using projects such as Openfire and Smack:

    1. Develop Proof-of-Concepts (PoCs): It’s possible to build early prototypes of messaging solutions to explore how the new standard might work in practice. Many core specifications are already implemented in our products, so prototypes can focus on workflow and interoperability rather than reinventing basic features.
    2. Experiment with Custom Functionality: The modular architectures of projects like Openfire and Smack make it possible to create custom plugins, extensions, or client features to test new communication ideas. Resources and examples from the project repositories can help get started.
    3. Explore Security and Privacy Configurations: By building prototypes, setting up test environments, or simulating messaging workflows, the community can experiment with authentication, encryption, and access control setups to see how patient data could be protected under the new standard.

    Let’s Build a Connected Dutch Healthcare Community

    Projects such as Openfire and Smack give us the building blocks to explore messaging that’s secure, reliable, and ready for the future. By experimenting, prototyping, and sharing insights, the community can help ensure the new Dutch healthcare chat standard meets real-world needs from day one.

    And since the Ignite Realtime Foundation is a Dutch stichting with local contributors and partners, we like to think of this as more than just coding - let’s discuss the possibilities over a stroopwafel sometime!

    For more information and to join the conversation, visit Ignite Realtime and introduce yourself in our community at disource.igniterealtime.org . Together, we can help Dutch healthcare teams communicate better and build a strong, collaborative XMPP ecosystem in the Netherlands.

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

    1 post - 1 participant

    Read full topic

    • Pl chevron_right

      ProcessOne: Europe's Digital Sovereignty Paradox - "Chat Control" update

      news.movim.eu / PlanetJabber • 13 October • 2 minutes

    Europe's Digital Sovereignty Paradox - "Chat Control" update

    October 14th was supposed to be the day the European Council voted to mandate scanning of all private communications , encrypted or not.

    The vote was pulled at the last minute.

    Germany withdrew support, creating a blocking minority that blocked the Danish Presidency&aposs hope to get the text approved. Denmark still hopes to push this through by the end of its EU presidency in December. I personally would like to be optimistic and think that the tech community managed to raise enough concerns with EU policymakers.

    Hundreds of European companies such as Proton, NordVPN, Tuta, Murena, Element, ProcessOne voiced their concerns about Chat Control. These companies are building the European alternatives we need for digital sovereignty. They offer what the EuroStack coalition is demanding: local infrastructure, values-driven technology, independence from US hyperscalers .

    And EU policy trying to force them to break the very protocols that make sovereignty possible does not seem like the wisest strategic move.

    What policymakers are missing is that encryption is a built-in foundation of most communication protocols . You cannot turn it on or off depending on what is considered right in a given place at a given moment. You either have secure end-to-end encryption or you don&apost. There is no "just this once" exception that doesn&apost become an exploitable technical or administrative vulnerability.

    When Denmark&aposs Justice Minister suggested that the "completely misguided perception" is that everyone has a right to secure communication, he revealed the fundamental gap: policymakers who don&apost understand that secure infrastructure is the core of today&aposs Internet backbone, not just for the pure sake of democracy (I swear it hurts to have to explain this), but also for the existential security of European countries.

    Today, European countries are prioritizing defense spending while missing that digital infrastructure is the battlefield. Networks allow us to control drones, spread misinformation, they are vectors of attacks on critical infrastructure.

    It is time for Europe to develop a coherent tech strategy . Can we build digital sovereignty while simultaneously undermining the protocols that enable it? Can we demand independence from US tech giants while forcing European alternatives to adopt vulnerabilities that US companies will try to avoid through commercial pressure?

    The October postponement is an opportunity. Two months for actual infrastructure builders and engineers to inform policy. Two months to bridge the gap between Brussels&apos political vision and the technical reality of how secure systems actually work.

    This is exactly the gap I work to bridge: between policymakers who understand the geopolitical stakes and engineers who understand protocol layers. Europe&aposs path to digital sovereignty requires both.

    Denmark&aposs December push will show us whether Europe is serious about learning from its own technical community, or whether we&aposre condemned to keep making policy that contradicts our stated goals.

    The European way should be: tech with purpose, built on sound engineering, serving democratic values. Not tech policy that undermines the very infrastructure we need to achieve independence.

    • Pl chevron_right

      Sam Whited: 2025-09-30 Trolley Barn Contra Post Mortem

      news.movim.eu / PlanetJabber • 11 October • 8 minutes

    The first time I DJed for a Contra Dance 1 was at Inman Park’s famous Trolley Barn. At the time I was DJing in the way other social dances are normally DJed: I had a laptop, I played a song, everyone danced. No fancy mixing, or effects: the most technical thing I did was loop 32 bar sections of music to stretch it out until the caller was ready to end the dance.

    This time around, returning to the Trolley Barn, I wanted to see if my DJ skills had improved and try live mixing for the first time. Since I’ve never heard of anyone else DJing a traditional contra dance 2 I didn’t have a good idea of what I was doing but I worked with the caller, my friend Valerie Young, to plan a set that I thought the dancers would like. The set comprised mostly high energy contra dance bands who play traditional songs in less traditional ways: think the Gaslight Tinkers , Great Bear , and ContraForce . My goal is to be able to tell the caller, “just treat me like a band” so that I can play a medley of two or more songs (as the band would traditionally do), they can request a tempo, energy level or vibe, and signal me when they’d like to end the dance and I’ll get ready to wrap up the mix with a nice ending. I don’t think I quite achieved that goal with this set, but it was close and the dancers had a blast either way, even if occasionally some of them ended up out on the ends when the dance wrapped up due to me not being able to give the caller as many times through as she wanted and still make the ending sound clean.

    Prep

    I prepped the individual music in this set basically the same way I did last time: in Mixxx I marked each time through the dance (contra has a very specific form) with color-coded loops or hot cues depending on if they looped cleanly or not, and named the mix-in and mix-out points when I decided what song to pair them with.

    A picture of the Mixxx user interface, specifically the deck region. The song “FIDDLE DISCO!” is loaded and several green loops, red and orange hot cues, etc. are selected with labels like “Skip to 4”, “Bridge” or “Buildup”

    I try to come up with enough mixes to fill the night, plus a few more that are both high and low energy to have in my back pocket in case the caller is just feeling a certain way that night. This way I hopefully always have something that I’ve practiced which works well for each dance in terms of where bouncy or smooth sections of the song fall. That said, I didn’t do a good job of matching songs to dances in every case this night (I would have liked songs with a harder hit on a few of the petronellas), but overall it worked well.

    The Set

    The night started out with the dance “ Jefferson’s Sixpence ” by Ann Fallon to which I played a mix of Gaslight Avenue and Reel du Nord , both by The Gaslight Tinkers. This went okay except that I let the track run a bit far before the caller was ready to stop and had to loop the same section a couple of times to make the mix keep working smoothly, which I felt got a bit boring after a handful of times through the dance. The dancers didn’t seem to notice or mind though and were enthusiastic about the start to the evening.

    Please excuse the clipping on the recordings, one of the unfortunate problems with the evening (that we’ll come to later) is that the gain on the main board was up way too high and I didn’t have control over that, so it was clipping most of the night. More on that in the retrospective at the end of this post.

    Gaslight Avenue / Reel du Nord by the Gaslight Tinkers, DJ mix

    The second song was a more traditional contra song, a mix of Highland by Wake Up Robin and Fleur de Mandragore by the Free Raisins to the dance “ Made Up Tonight ” by Erik Hoffman. Due to some technical difficulties with the sound pulled from the main board I didn’t wind up with a recording of this one (or most of the following songs), so let’s just pretend the mix went perfectly and everyone had a good time.

    Next the caller picked “Trip to Elsan” by Joe Surdyk and Eric Schreiber. For this I branched out a bit, mixing the (more or less) traditional contra song, Basketball by Countercurrent with FIDDLE DISCO! by Elias Alexander . I had one minor issue with the mix towards the end of FIDDLE DISCO! , a loop that wasn’t really clean but was necessary for the number of times through the dance the caller wanted, but the dancers didn’t seem to notice and they went wild for the modern beats that the tune introduces! This was also the first time I had to re-mix a tune a bit on the fly besides just transitioning between two tunes since FIDDLE DISCO! is crooked and won’t work for contra dancing without (minor) adjustments.

    Basketball / FIDDLE DISCO! by Countercurrent and Elias Alexander, DJ Mix

    The Tuesday night Trolley Barn dance is rather short, so we took a waltz break at this point. I played Here Comes Sunshine by George Paul at the callers request, and Les Yeux Noirs by Burçin since I knew that a number of people from the local Lindy Hop scene were in the crowd. The switch to swing made those dancers happy, even if it confused the waltzers.

    Back in the main dance I did a mix of Lafferty’s and Camel Hump by Wild Asparagus to one of my personal favorite contra dances: Tika Tika Timing by Dean Snipes.

    Afterwards came what I thought was going to be the second to last song of the evening (we’d been running dances a bit long and were short on time) so I pulled out the show stopper: a medley of Griffin Road and Trip to Moscow , both by Kingfisher , but I added a little contra joke by mixing Rasputin by Boney M in with Trip to Moscow , purely based on the name (but the combo also just worked really well). This one really brought the house down!

    I didn’t get a recording of this one, sadly with all the times through, but here was the backup recording I made in advance in case my laptop died during the show or something. The transition sounds like I had a buffer underflow (or just bad timing) on this one, and the mixing is a bit iffy in places, but trust me, it was better live!

    Griffin Road / Trip to Moscow / Rasputin by Kingfisher and Boney M, DJ mix

    At this point one of the organizers said she was having such a good enough time that she offered to let us run a bit over so we added “Vivian’s Catwalk” by Valerie herself to a mix of Muscles / Ride the Wheel by Buddy System and Garbage in A by Great Bear. This went well, except that I had layered the percussion from Garbage in A into Ride the Wheel so that when the transition happened it would have some continuity. Except that I somehow wound up off the beat and had to absolutely scramble to beat match; it sounded terrible, but somehow it didn’t throw Valerie off and once I finally got it beat matched we were still right on time.

    For the final tune of the evening Valerie picked “ Frock’s Rockin Frolick ” by Will Mentor which works great as either a high or low energy dance depending on the caller. To compliment this I brought the energy down a bit with a mix of Brand by Potent Brew and El Bourbon Grande by ContraForce which brought the energy right back up to the high point by its rather loud ending!

    Finally we closed the evening down with Ootpik Waltz by Wild Asparagus.

    Stuff I Learned

    • Either ask to do sound yourself, or don’t be afraid to ask the sound person if something sounds wrong (I didn’t want to be rude, so I didn’t ask, but they didn’t realize it was clipping all night and I’m sure they would have fixed it had I mentioned it!),
    • I meant to both record my set on my laptop (no caller) but also record the main outputs from the board with a portable recorder (with caller), and ended up with only a few of the songs actually recorded. You have to actually remember to start recording…
    • Prep endings better, if there are no clean loops near the end of the song, prepare a different ending or get better at covering the bad loop with effects or something. I had a few times where the caller asked for “3 more times” or “2 more times” and I had to say “uhhh, how does 1 or 3 sound?” or something along those lines. This was fine with my friend Valerie, but isn’t going to make you any other callers favorite band to work with.
    • The jog wheels on the Traktor Kontrol S4 MK3 aren’t big enough. Do I do anything that technically means I need bigger jog wheels? No. Would I feel better about having them? Yes. Unfortunately the only controller that meets all my requirements and has bigger job wheels is the Rane Performer, and that’s way out of my price range (and will likely remain so forever), so maybe this is a “learn to get over it” type situation.
    • Don’t just assume the waltz breaks don’t matter, they’re still part of your set and should be selected with care (the tempo was way too fast too, gotta pay more attention to the waltzes in general).

    Other Links


    1. If you’ve never seen a contra dance, imagine the kind of polite folk dance in long lines you’d see in a movie of a Jane Austin book, then turn it into a rowdy barn dance in the style of square dancing except you dance with (mostly) every single person in the room during each dance instead of just the 7 other people in your square. More info can be found on Wikipedia . ↩︎

    2. Traditionally all contra dances are live music unless they are “techno-contra” (meaning contra to non traditional music, normally pop, not actual Techno music), so I’ve seen EDM or similar DJs play for contra dances, but never a DJ mixing music meant for contra dances. ↩︎

    • Pl chevron_right

      ProcessOne: Why Europe's 'Chat Control' Proposal Will Cripple European Communication Industry While Failing to Protect Children

      news.movim.eu / PlanetJabber • 22 September • 6 minutes

    Why Europe's 'Chat Control' Proposal Will Cripple European Communication Industry While Failing to Protect Children

    On October 14th, the European Parliament will vote on a regulation that could effectively dismantle Europe&aposs emerging decentralized messaging ecosystem, and shake the broader European communication industry while failing to protect the children it claims to defend. Driven by Denmark&aposs fierce advocacy during its EU presidency, proposal 11596/25 – labeled &aposChat Control&apos by privacy advocates – finally faces a decisive moment after years of debate.

    The proposal seems straightforward: require platforms to scan for child sexual abuse material. But the technical reality reveals a devastating contradiction : it demands the impossible from open, federated European alternatives while handing structural advantages to the very American tech giants Europe claims to want to regulate.

    What the proposal actually requires

    Proposal 11596/25 targets child sexual abuse material across a large range of services operating in the European Union: hosting services, interpersonal communications services, software application stores, internet access services, and online search engines. Under this regulation, these providers would be required to detect illegal content (images, URLs, text), report it to authorities, and remove it.

    The scope goes far beyond what the European Parliament previously considered acceptable. In its balanced approach to child protection, Parliament explicitly rejected "widespread web scanning, blanket monitoring of private communications or the creation of backdoors in apps to weaken encryption." See: How the EU is fighting child abuse online .

    This proposal abandons that restraint. It creates an obligation for service providers to scan all user traffic – encrypted or not – in search of illegal materials. More critically, it requires scanning private chat conversations before content is encrypted, not just publicly available content.

    The risk of surveillance overreach

    While child protection is undeniably crucial, the surveillance mechanisms described in this regulation create infrastructure that could threaten fundamental civil liberties . Once governments possess the technical capability to scan all private communications before encryption, the temptation to expand its use becomes overwhelming.

    The concern isn&apost about protecting illegal content, it&aposs about protecting democratic discourse. Private conversations could become subject to monitoring based on shifting political definitions of harmful speech. What begins as child protection infrastructure could evolve into a tool for suppressing political opposition or monitoring dissenting opinions in private communications.

    The infrastructure created for child protection becomes the foundation that future governments — potentially less democratic ones — could leverage to monitor any communications they consider threatening to their power.

    This is what privacy advocates primarily focus on, and their concerns are valid. However, as operators of messaging infrastructure, we face more immediate technical realities that make this regulation unworkable regardless of its civil liberties implications.

    Why the technical requirements are impossible to implement

    As operators of XMPP messaging infrastructure in sensitive industries, like for example the medical sector, we face the practical reality of what this regulation would require. The technical demands in Articles 7 and 10 reveal fundamental misunderstandings about how modern communication systems actually work.

    The architectural reality: In-band vs. out-of-band content

    Modern messaging platforms fundamentally separate data types. Messages and protocol data transfer "in-band" through the messaging protocol, while binary content like images and documents transfers "out-of-band" because files are too large for messaging channels.

    This creates an immediate problem for the regulation&aposs scanning requirements. When doctors share diagnostic images through our XMPP platform, the system works like this:

    • Clients negotiate the exchange via XMPP (metadata visible to server)
    • The medical file transfers peer-to-peer or via HTTPS upload with a unique, secure link
    • The messaging server never sees the actual content – only the negotiation

    The regulation can only scan in-band messaging content and metadata, not the out-of-band transfers where sensitive material could actually reside. It will break confidentiality of legitimate medical discussions without accessing the data it claims to monitor.

    The open protocols impossibility

    Article 10.1&aposs requirement to scan "prior to transmission" in end-to-end encrypted services assumes complete client control -- something impossible with open protocols like XMPP.

    The regulation demands that service providers guarantee scanning occurs before encryption on every client. But XMPP is a standardized, open protocol where anyone can develop compatible clients. On an average XMPP server, more than 30 different clients coexist. How can we guarantee that each client respects scanning obligations when we cannot control their code?

    The problem deepens with federation. XMPP servers interconnect, allowing users on different servers to exchange messages. When a message arrives from another server, it&aposs already been end-to-end encrypted by a client we have no control over. There&aposs no technical mechanism for the receiving server operator to enforce scanning requirements on clients that are not directly connected on its platform.

    This creates an absurd regulatory requirement: we would need to either abandon open standards entirely or somehow police every piece of software that implements XMPP, including modified open-source clients that users could easily deploy to bypass scanning.

    The circumvention reality

    Real criminals can easily bypass these measures through three complementary approaches that the regulation fails to address:

    Distributed architecture: Store content on external servers and share only URLs through chat, exactly what legitimate services like our XMPP platform already do naturally for file transfers.

    External encryption: Encrypt content with PGP, GnuPG, or OpenSSL before uploading it anywhere, making scanning meaningless regardless of the platform&aposs capabilities.

    Modified clients: Use altered XMPP or Matrix clients that automatically implement these behaviors, exploiting the same open-source flexibility that makes compliance impossible.

    The result is predictable: the regulation will only catch criminals amateur enough to send illegal content directly as unencrypted attachments through unmodified clients. Meanwhile, it subjects all legitimate communications of European citizens to mass surveillance.

    This isn&apost theoretical speculation. These methods are already standard practice across European messaging infrastructure, used by both legitimate services and bad actors alike.

    The programmed death of European alternatives

    This regulation creates a structural disadvantage for European communication services trying to build alternatives to American tech giants.

    Complexity favors incumbents

    Annex XIV reveals a scoring system of Kafkaesque complexity, requiring considerable resources for compliance. This complexity structurally favors large platforms, usually Americans, that can:

    • Deploy massive financial resources to adapt their systems
    • Control their closed ecosystems completely
    • Distribute compliance costs across billions of users

    The decentralized ecosystem under threat

    Meanwhile, Europe&aposs emerging decentralized alternatives face impossible technical requirements. There are currently tens of thousands of independent XMPP servers, federated Matrix deployments, and GDPR-compliant solutions that represent Europe&aposs best chance for digital messaging independence . Can they comply with obligations designed around centralized architectures?

    We operate several messaging servers on behalf of customers. Under this regulation, we face a stark choice: shut down services we cannot control completely, from clients to servers, or force our European clients to migrate for example to Microsoft Teams to avoid regulatory complications.

    Conclusion

    This technical analysis reveals a regulation that fails on multiple levels. It demands technical impossibilities from European service providers while offering trivial workarounds for actual criminals. It structurally advantages American tech giants over European alternatives at precisely the moment Europe seeks digital independence.

    For communication service operators, this regulation creates an impossible choice : abandon open protocols and federated architectures that represent Europe&aposs best path to messaging independence, or face legal risks with high mitigation costs even in lawful, legitimate use cases.

    The October 14th vote represents more than a policy choice about child protection. It&aposs a decision about whether Europe will cripple its own communication infrastructure in pursuit of surveillance capabilities that won&apost work as promised.

    The current compromise proposal has been shared here: Proposal for a Regulation of the European Parliament and of the Council laying down rules to prevent and combat child sexual abuse - Presidency compromise texts . This seems is the most up to date version of the text I could find. Read the text and make your own assessment of whether Europe can afford to implement technical requirements that its own industry cannot comply with.

    • Pl chevron_right

      Ignite Realtime Blog: Openfire 5.0.2 release!

      news.movim.eu / PlanetJabber • 15 September • 1 minute

    The IgniteRealtime community is happy to announce a new release of its open source, real-time communications server server Openfire! Version 5.0.2 brings a number of stability improvements and bug fixes.

    Notably, it addresses a recently identified security vulnerability, identifies as CVE-2025-59154 . The issue allows for potential identity spoofing via unsafe Common Name attribute parsing. It is mostly applicable to what we perceive to be niche use-cases of Openfire. Please read the full security advisory for more information.

    Openfire 5.0.2 is a bugfix release, with various bugfixes and improvements. Of particular interest to some will be the improvements made to the SystemD-based scripts (used in many Linux environments), which remove a few annoyances that were introduced in Openfire 5.0.1. Please refer to the full changelog for more details.

    You can obtain the new version of Openfire for your platform from its download page . The checksums for the binaries are:

    4e907c615b3a19af0a1b5ab68ae24825b737496f9cf1715c9feafe8f909086da  openfire-5.0.2-1.noarch.rpm
    21271a6f22895852e50712236c45c7d213430171d5a3178474b8398f036ac07a  openfire_5.0.2_all.deb
    06794a12acdd8f23ca3c40fcd7af1677d8108b4b23bb72424c2751b30cfb3d14  openfire_5_0_2.dmg
    c1e830b5e016d0bcff40005cc7bb14c846fe0ec26fc5a3fc967c30e5b6d2e356  openfire_5_0_2.exe
    c84ca15cd470d3233add97c852c738eb373859dc9968ad34ec581725164c8114  openfire_5_0_2.tar.gz
    98b5cf96326c668efb18cd9347b808a5ef85162b4a0b703aaf8e29d82cc6c727  openfire_5_0_2_x64.exe
    8e09ca3dc7fb84b116ce95d10bfa3ff045708cdac4b23bd3d78ccf318e8742d8  openfire_5_0_2.zip
    

    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

    • Pl chevron_right

      JMP: Newsletter: (e)SIM nicknames, Cheogram Android updates, and Cheogram iOS alpha

      news.movim.eu / PlanetJabber • 8 September • 2 minutes

    Hi everyone!

    Welcome to the latest edition of your pseudo-monthly JMP update! (it’s been 7 months since the last one 😨)

    In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client. Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

    Alerts for incoming messages blocked by Original route

    The partner that serves our Original route has for some time been censoring some incoming messages, meaning messages from friends and family to you might occasionally be blocked. We have finally managed to get them to tell us when this happens and so we now relay an alert to you, so you can know this has happened and ask your contact to try rewording their message. Reminder that we do offer other routes for those having issues with this. Contact support if this interests you.

    (e)SIM nicknames

    If you have multiple (e)SIMs through JMP , keeping track of which is which by its ICCID can be a pain. Now you can give each a nickname by opening commands with the bot , tapping 📶 (e)SIM Details or sending the sims command, then selecting Edit (e)SIM nicknames

    Some updates to Cheogram Android this year

    • Scanning a Snikket invite works for new accounts
    • Search UI for emoji reactions (including custom emoji)
    • Display notifications for calls missed while offline
    • Don’t clear message field after uploading something
    • Allow selecting text in command UI
    • Initial support for community spaces
    • Show dot on the drawer for unseen, unread messages like chat requests
    • Second message edits no longer treated as separate messages1

    Inherited from upstream Conversations

    • Conversations 2.18.0
      • Select backup location
      • Make more URIs, like mailto: , clickable

    Cheogram iOS

    We’ve been working on an EXPERIMENTAL native client for iOS using Borogove (previously called Snikket SDK). It’s available through Testflight for the adventurous, and push notifications require a Snikket server running the dev version for now. Contact support if you’re both interested in testing it and willing to provide feedback.

    JMP at FOSSY

    We sponsored FOSSY 2025 and had a great time meeting community members! After giving a few talks, having fun at the social, and selling some subscriptions , (e)SIMs , and (e)SIM adapters , we’re looking forward to seeing everyone again next year in Vancouver, Canada !


    To learn what’s happening with JMP between newsletters, here are some ways you can find out:

    Thanks for reading and have a wonderful rest of your week!


    Amolith
    https://secluded.site