call_end

    • chevron_right

      Erlang Solutions: Meet the Team: Márton Veres

      news.movim.eu / PlanetJabber • 7 days ago - 10:23 • 2 minutes

    Say hello to Márton Veres, our new Business Unit Leader for London.
    From international consulting to leading delivery teams, Márton’s journey to this role has been anything but ordinary. In our latest team interview, he shares what excites him most about this next chapter, his vision for growing our presence in London, and a personal challenge he’s set for the summer.

    Get to know Márton and his take on leadership, community, and what’s ahead.

    Marton Veres

    Congratulations on your new role as Business Unit Leader (BuL) for London. Could you share more about your new role at Erlang Solutions?

    Thanks! I’m proud to take on the BuL role after four years in project and delivery management here. I’ll be leading the London team, shaping and executing our business strategy, and driving growth through client relationships and new opportunities.

    I’m looking forward to working more closely with our UK colleagues, connecting with the Erlang and Elixir communities, and strengthening our presence in the London market.

    What have been some highlights of your career so far?

    My journey has always been at the intersection of business and technology. I spent my first eight years as an IT consultant in FinTech and Telco, helping align business needs with tech solutions. Then, I led project management teams at Deutsche Telekom for eight years, gaining deep experience in large-scale delivery.

    At Erlang Solutions, I’ve worked alongside brilliant engineers on cutting-edge Erlang and Elixir projects. The mix of consulting, corporate, and agile tech environments has given me a well-rounded perspective that I bring into this new role.

    What are you most looking forward to in your new position?

    I’m especially excited to deepen our work in London’s FinTech, Digital Health, and Energy sectors. I’m passionate about supporting and growing our team using servant leadership and business coaching skills I’ve developed, including through a recent certification programme supported by Erlang Solutions.

    Digital Health is a particular interest of mine, and I’d love to expand on the work we’ve done with the NHS, HCA Healthcare, and Baxter. Being part of the Trifork Group also opens up opportunities to collaborate on end-to-end solutions, especially with their Digital Health expertise.

    Outside of work, what are you most excited about this summer in London?

    I’m training for the Wimbledon Half Marathon in September. My goal is to finish in under two hours! It’s a great way to stay focused and make the most of the summer. Balancing work and personal goals like this keeps me energised.

    Final thoughts

    It’s been a pleasure catching up with Márton and hearing about his journey, leadership vision, and what’s ahead for the London team. His story is a great reminder of the passion and purpose that drive our work at Erlang Solutions.

    We’ll be sharing more team stories soon. So keep an eye out for the people behind the projects. If you’d like to connect with Márton or anyone on our team, we’d love to hear from you.

    The post Meet the Team: Márton Veres appeared first on Erlang Solutions .

    • chevron_right

      Ignite Realtime Blog: Openfire 5.0.0: A New Era of Real-Time Communication

      news.movim.eu / PlanetJabber • 20 June • 2 minutes

    We are thrilled to announce the release of Openfire 5.0.0, the latest version of our popular open-source XMPP (Extensible Messaging and Presence Protocol) server. This release marks a significant milestone in our journey to provide a robust, scalable, and secure platform for real-time communication.

    Openfire 5.0.0 comes packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. Here are some of the key highlights:

    1. Enhanced Security: We’ve made significant improvements to Openfire’s security infrastructure. These include the restoration and improvement of Certificate Revocation support, implementation of XEP-0421 for anonymous unique occupant identifiers in MUCs and updating Jetty’s embedded webserver for enhanced stability.
    2. Improved Performance: Openfire 5.0.0 is designed to handle larger loads more efficiently. We’ve optimized the server’s performance to ensure it can scale to meet the needs of your growing user base. Performance improvements include updating our network interaction layer with a recent version of Netty, optimizing database queries, and reducing duplicate code in multi-providers, resulting in a more efficient and responsive system.
    3. Plugin Updates: We’ve updated several of our core plugins to ensure they’re compatible with Openfire 5.0.0. This includes updates to our monitoring, clustering, and web-based chat client plugins.
    4. Bug Fixes and Improvements: We’ve squashed numerous bugs and added various features in this release, improving the overall functionality, stability and reliability of Openfire. Translations have been updated (and now include Turkish, Swedish and Italian), new group chat management features have been added, and parallelism when working with many federated domains has been improved, to name a few.
    5. Updated Java Requirement: Openfire requires Java 17 (or newer) to be installed.

    Our deepest thanks go to NLnet Foundation for their invaluable support. With their funding and encouragement, we successfully implemented full IPv6 support and completed a robust security audit by Radically Open Security. NLNet’s mission to strengthen open and trustworthy internet infrastructure continues to make a real difference!

    The changelog lists all of the changes that have been made.

    We’re incredibly excited about this release and we can’t wait to see what you’ll build with Openfire 5.0.0. Whether you’re a developer looking to build a new real-time application, or an organization looking to improve your communication infrastructure, Openfire 5.0.0 has something for you.

    As always, Openfire is free and open-source, so you can download it, use it, and modify it to suit your needs. We believe in the power of open-source software to drive innovation and we’re committed to continuing to support and develop Openfire.

    Thank you to everyone who has contributed to this release, whether by submitting code, reporting bugs, or providing feedback. Your contributions are invaluable and we couldn’t do this without you.

    You can download Openfire 5.0.0 from our website and check out our documentation to get started. We’ve also updated our community forums where you can ask questions, share ideas, and connect with other Openfire users.

    Here’s to the future of real-time communication with Openfire 5.0.0!

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

    2 posts - 2 participants

    Read full topic

    • chevron_right

      Ignite Realtime Blog: Openfire 5.0.0 beta release

      news.movim.eu / PlanetJabber • 12 June • 1 minute

    It is exciting to be able to announce the immediate availability of the beta release of Openfire 5.0.0!

    In this release, we have addressed approximately 125 issues! I’ll reserve the details for a blog post on the 5.0.0 (non-beta) release, but some of the important changes are:

    • We’ve dropped support for Java 11. The minimum requirement is Java 17 now
    • The embedded web server has received a major upgrade
    • Various security-related updates were applied, including library updates and code changes that resulted from an independent security audit (more on that later!)

    This beta release (and some of its precursors) have been extensively tested by the developers and other members of the Ignite Realtime community. At this stage, we’re not seeing any critical issues. However, prior to cutting the full release, we prefer to have more feedback. That is where you come in!

    We are looking for your help!

    Please help us test this release! If you host your own instance of Openfire, please consider upgrading it to the new beta release. If you can’t, or if you’re not running Openfire but another brand of XMPP server, please do some interoperability testing with the server at igniterealtime.org .

    Are you a client developer? Please see how your application behaves, when connecting to the beta (we can make available accounts for testing to help you do this).

    If you’re nothing of a tech-head but can use an XMPP client, try to interact with our domain (for example, join our chatroom at open_chat@conference.igniterealtime.org ) to see if there are any issues.

    You can obtain the beta from our download page for beta releases or from the GitHub Releases page .

    We would love to hear from you! If you have any questions, please stop by our community forum or our live groupchat . We are always looking for volunteers interested in helping out with Openfire development!

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

    1 post - 1 participant

    Read full topic

    • chevron_right

      JMP: Mitigating MITMs in XMPP

      news.movim.eu / PlanetJabber • 5 June • 5 minutes

    In October 2023, Jabber.ru, “the largest Russian XMPP messaging service”, discovered that both Hetzner and Linode had been targeting them with Machine-In-The-Middle (MITM) attacks for up to 6 months. MITM attacks are when an unauthorised third party intercepts traffic intended for someone else. At the point of interception, the attacker can inspect and even modify that traffic. TLS was created to mitigate this; all communication between the two parties is encrypted, so the third party sees nothing but gibberish (ciphertext).

    TLS is great, but it’s actually not enough when the attacker owns your network, as in Jabber.ru’s situation. Jabber.ru rented servers from Hetzner and Linode, who altered their network’s routing setup to obtain TLS certificates for Jabber.ru’s domains and successfully carry out a MITM. When connecting to an XMPP server, most clients are only configured to look for a valid certificate. A valid certificate matches the service’s domain name, is not expired, and is authorised by a known and trusted Certificate Authority (CA). If the client sees a certificate that’s signed by an unknown CA or whose expiry has passed or the domain in the cert doesn’t match the service domain or any combination of the those, it’s considered invalid; the client should terminate the connection before transmitting sensitive data, such as the user’s password.

    Because Hetzner and Linode controlled Jabber.ru’s network, they were able to meet all of those conditions. XMPP clients would just accept the rogue (but valid!) certificates and continue along as normal, unaware that they were actually connecting to a rogue server that forwarded their traffic (possibly with modifications) to the proper server.

    A fairly straightforward mitigation involves DNS-based Authentication of Named Entities, or DANE. This is just a standard way to securely communicate to clients what certificate keys they should expect when connecting. When clients initiate a connection to the XMPP server, they receive a TLS certificate that includes a public key. If the server admin has implemented DANE, the client can verify that the public key they received matches what the server administrator said they should receive. If they don’t match, the client should terminate the connection before transmitting sensitive data.

    Please note that while this post continually refers to DANE as it relates to XMPP, it could just as easily refer to any system that uses TLS, such as SMTP, Matrix, Mattermost, Rocket Chat, and more. The servers don’t need to do anything with DANE, just the clients connecting to the servers.

    Additionally note that this doesn’t mitigate cases where a provider has access to the server’s filesystem. If it’s a VPS, the provider could just snapshot the virtual disk and pick out the certificate files (as well as any other files they find interesting). If it’s a baremetal server, they’d have a harder time interacting with the filesystem without notifying the owner of their presence, but they could definitely still do it. Physical access is equivalent to root access.

    DANE requires the XMPP server’s authoritative nameserver, TLD, and domain registrar to all support DNSSEC. If those prerequisites are met, implementing DANE involves hashing the public keys of the current certificates and publishing them to DNS as TLSA records. The following commands extract the public key from a local PEM-encoded x509 certificate, re-encode it to DER, then hash it and print the hash.

    $ openssl x509 -in xmppserver.example.pem -inform pem -pubkey -noout \
      2>/dev/null | openssl ec -pubin -outform der 2>/dev/null | sha256sum \
      | awk '{print $1}
    
    9ff8a6d7aab386dfbd8272022d04f82204d1093332e6fc33d1c55ee21e0aedd0

    The long sequence of letters and numbers is the hash of the key and what gets published to DNS. The following commands initiate a connection to retrieve the certificates, extract and convert the public key, then hash it and print the hash.

    $ echo | openssl s_client -showcerts -servername xmppserver.example \
      -connect 198.51.100.7:5270 2>/dev/null | openssl x509 -inform pem \
      -pubkey -noout 2>/dev/null | openssl ec -pubin -outform der \
      2>/dev/null | sha256sum | awk '{print $1}'
    
    9ff8a6d7aab386dfbd8272022d04f82204d1093332e6fc33d1c55ee21e0aedd0

    When it comes to rotating certificates, admins have two options. The first and easiest is to reuse the key-pair from the original certificate. Certbot allows you to do this with the –reuse-key option. Caddy has an equivalent option. The other route is rotating both the certificates and the key-pair. This should be done well before the certificates expire. After obtaining the new certificates and keys, do not immediately swap them into production! Hash the new keys, then publish them as new TLSA records. Wait at least two TTLs, then swap the new certificates in and replace the old ones. Wait at least two more TTLs, then remove the TLSA records corresponding to the old key-pair.

    Waiting in between steps is necessary to reduce false positives and mitigate race conditions. Say the TTL is two hours and a client connects half an hour before the administrator starts rotating things. They obtain the new keys, hash them, publish the hashes, then swap the certificates and reload the XMPP server. Say the client reconnects five minutes after the administrator finishes. It’ll receive the new certificate file, but not pick up on the new record because administrator has said, through the two-hour TTL, that resolvers should only request DNS records once every two hours. For the next 1h25m, until the cache expires and their resolver re-requests all the TLSA records, the client will refuse to connect to the server and might even warn the user that the server and their account are compromised. Waiting two more TTLs before removing the old record is necessary to handle the very unlikely event where the client connects and receives the old certificate file right before the admin removes the old record. If they check DNS for that old, now-missing record after receiving the old certificate, the client should refuse the connection.

    danectl is a tool that uses Certbot to create and manage certificates and key-pairs, it generates BIND9 DNS records you can copy/paste into your DNS management tool, and even verifies that you’ve published the records correctly. It also works with SSHFP records to implement DANE with SSH servers, OPENPGPKEY records for GPG keys, and SMIMEA records for S/MIME certificates.

    Some clients are currently unaware of DANE, so it can be helpful to monitor TLS setups through an external service. Later in 2023, we created and announced a tool to fill this gap, CertWatch . You provide your XMPP server’s domain and it performs the same checks a client would over Tor, to prevent easy detection by an attacker.

    • wifi_tethering open_in_new

      This post is public

      blog.jmp.chat /b/mitigating-mitms-in-xmpp

    • chevron_right

      Erlang Solutions: Avoiding Common Startup Tech Mistakes

      news.movim.eu / PlanetJabber • 5 June • 7 minutes

    When you’re moving quickly in a startup, taking shortcuts in your tech stack is tempting. A quick workaround here, a temporary fix there, with plans to tidy it all up later. But later can easily turn into never.

    Those early decisions, however small they seem, have a habit of sticking around. Over time, they slow you down, create technical debt, and make it harder to scale.

    This blog looks at how to avoid common startup tech mistakes by making smarter choices early on. You don’t need to build the perfect system from day one, but you do need to build something you won’t regret.

    The risks of rushing your tech stack decisions

    Your tech stack is the foundation of your product. Making quick choices to just keep things often comes with hidden costs.

    Common examples of early tech shortcuts

    • Choosing tools based on ease rather than long-term fit
    • Using third-party services without proper integration planning
    • Avoiding proper system design to save time
    • Stacking too many frameworks or libraries to plug gaps quickly
    • Skipping documentation, testing, or version control in the name of speed

    What could go wrong?

    Here are some of the common risks that come with rushing tech stack choices:

    Risk Impact
    Technical debt Every short-term choice adds friction later. Over time, progress slows as the team spends more time managing issues than delivering value.
    Security gaps Fast fixes can lead to poorly secured systems, especially when sensitive data is involved or best practices are skipped.
    Fragile foundations A patchwork stack becomes hard to maintain, debug, or scale, and onboarding new developers becomes a headache.
    Scaling problems Systems built for “now” can’t always support growth. Quick fixes often ignore load handling, resulting in slowdowns or breakdowns at scale.
    Innovation slowdown When all your energy goes into fixing past decisions, there’s little room left for building what’s next.

    The business cost of technical shortcuts

    They directly impact a startup’s ability to grow. From wasted dev time to lost customer trust, the cost of early shortcuts adds up fast. That’s not the kind of overhead most startups can afford.

    The long-term cost of technical debt

    We touched on technical debt earlier as one of the key risks of rushing early tech decisions. Now let’s look at it more closely, because for many startups, it’s the most persistent and costly issue that comes from cutting corners.

    Technical debt is the build-up of compromises made during development, from skipping tests and rushing features to patching bugs without addressing their root cause. These short-term choices eventually slow everything down, making it harder and more expensive to move forward.

    Let’s break down the long-term impact:

    The hidden costs of technical debt

    Consequence What it means
    Slower development Developers spend more time fixing old issues than building new features, reducing overall velocity.
    More bugs, more fire-fighting Poorly maintained code leads to more frequent and severe bugs, increasing customer support and downtime.
    Low team morale Constantly dealing with messy code creates frustration and burnout, which can hurt retention.
    Harder to scale As the product grows, tech debt makes it harder to add new features or pivot without causing breakages.
    Security risks Outdated code or rushed fixes often introduce vulnerabilities that can be exploited later.
    Increased costs Fixing problems later is far more expensive, both in time and budget.

    A Stripe report found developers spend up to 42% of their week handling technical debt. CIO research suggests 20–40% of IT budgets are spent addressing it.

    When it gets out of control

    Technical debt can halt progress entirely. We’ve seen startups and scale-ups locked into outdated or fragmented systems, where maintaining or updating anything becomes nearly impossible.

    Here are a few real-world scenarios:

    • Legacy overload : Systems running well past their intended lifespan, no longer supported or secure.
    • Integration failure : Poorly connected tools and services that don’t talk to each other, slowing everything down.
    • Scaling bottlenecks : Infrastructure so rigid that every new feature or user pushes it closer to breaking point.

    Security crises : Outdated code with known vulnerabilities, eventually forcing a full rebuild after a breach.

    What startups can do about it:

    You can’t avoid technical debt entirely, but you can manage it by:

    • Prioritising clean, maintainable code from day one
    • Setting time aside for refactoring and testing
    • Regularly reviewing architecture decisions
    • Choosing tools that support long-term scalability, not just quick wins

    Startups that manage technical debt proactively stay more adaptable, secure, and focused on building the future.

    Why scalability matters from day one

    Tech built in a rush might work for an MVP (minimum viable product), but without scalability and maintainability in mind, it becomes a liability, something we cover in more detail in our post on common MVP mistakes.

    60% of startups face major scalability issues within their first three years (McKinsey) . These problems aren’t just technical; they slow growth, frustrate users, and drain time and resources.

    Here’s why it’s critical to get it right from the start:

    1. Scaling later is harder and more expensive

    Retrofitting scalability into an existing product or tech is rarely clean. The cost (in both time and money) often outweighs what it would’ve taken to plan it earlier.

    2. Maintainable code accelerates growth

    Clean, modular code helps teams ship faster, fix bugs quicker, and onboard new engineers smoothly. Poor code slows everything down.

    3. Users don’t tolerate failure

    Unscalable systems break under pressure, which is exactly when users start showing up. That erodes trust, kills momentum, and makes customer retention harder.

    4. Bad tech choices can limit your future

    Tech that isn’t built to adapt can lock you into tools, vendors, or architectures that no longer serve your goals. That makes pivots and product evolution harder.

    Early-stage teams often defer these decisions to “later.” But in startups, later usually means too late . Thoughtful, scalable, and maintainable tech choices aren’t a luxury but a growth strategy.

    Doing it Right from the start: In practice

    Now that we understand why scalable and maintainable tech decisions are crucial early on, here are some practical strategies to help your startup avoid quick fixes and build a strong foundation.

    1. Prioritise Root Cause

    Don’t just patch, find and fix the real problem. For example, optimise slow database queries instead of repeatedly fixing slow responses.

    2. Adopt Agile

    Work in short cycles and use user feedback. Many fintech startups rely on agile to adapt quickly.

    3. Write Clean, Modular Code

    Keep code simple and flexible. Use modular design to evolve without costly rewrites.

    4. Test Early

    Use automated tests early to catch bugs. Improve stability by prioritising testing from the start.

    5. Review Regularly

    Hold frequent code and architecture reviews. Startups BoardClic and Metaito used expert code and architecture reviews to ensure scalable, robust platforms.

    6. Choose the Right Tech

    Pick tools that fit your goals and skills. Many startups use scalable, developer-friendly stacks like Elixir.

    7. Document Clearly

    Keep documentation up to date to help teams understand decisions and onboard new members fast.

    8. Don’t skip security checks

    It’s easier to fix security issues early than patch things up later. Audits, such as SAFE (Security Audit for Erlang and Elixir) , helped startups like Koll and Twine ensure the security of their systems early on, making it easier to scale with confidence and avoid nasty surprises.

    Starting with these habits cuts costly fixes later and sets your startup up for lasting growth.

    Balancing speed and quality without overengineering

    Startups must deliver quickly but avoid building overly complex solutions too soon. The key is focusing on essential features that address real user needs, while keeping the system flexible enough to adapt later. This helps avoid wasted effort on premature optimisation or unnecessary features.

    For more on this, check out our post: Common MVP mistakes: How to build smart without overbuilding .

    Build now, avoid startup tech mistakes later

    Startups move fast, but speed shouldn’t come at the cost of sustainability. Those early quick fixes and temporary solutions often end up sticking around. Over time, they slow you down, create technical debt, and make it harder to grow.

    You don’t need to build the perfect system from day one. But you do need a foundation that won’t hold you back.

    Make smart, thoughtful tech choices early. Keep things simple. Review regularly. Focus on value that lasts. That’s how you stay fast without sacrificing your future.
    If you’re ready to avoid common startup tech mistakes and build something that lasts, Erlang Solutions can help, so let’s talk .

    The post Avoiding Common Startup Tech Mistakes appeared first on Erlang Solutions .

    • chevron_right

      Prosodical Thoughts: Prosody 13.0.2 released

      news.movim.eu / PlanetJabber • 29 May • 1 minute

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

    This update addresses various issues that have been noticed since the previous release, as well as a few improvements, including some important fixes for invites. Some log messages and prosodyctl commands have been improved as well.

    A summary of changes in this release:

    Fixes and improvements

    • mod_storage_internal: Fix queries with only start returning extra items
    • mod_invites_register: Stricter validation of registration events

    Minor changes

    • MUC: Ensure allow MUC PM setting has valid value (fixes #1933 : PM does not work on new MUCs)
    • mod_storage_sql: Delay showing SQL library error until attempted load
    • mod_storage_sql: Handle failure to deploy new UNIQUE index
    • mod_storage_sql: Add shell command to create tables and indices (again)
    • mod_s2s: Fix log to use formatting instead of concatenation (fixes #1461 : Logging issues uncovered by mod_log_json)
    • modulemanager, util.pluginloader: Improve error message when load fails but some candidates were filtered
    • prosodyctl check config: add recommendation to switch from admin_telnet to shell
    • mod_storage_sql: Retrieve all indices to see if the new one exists
    • prosodyctl check config: List modules which Prosody cannot successfully load
    • net.http.files: Fix issue with caching
    • util.jsonschema: Fix handling of false as schema
    • mod_invites: Consider password reset a distinct type wrt invite page
    • configmanager: Emit config warning when referencing non-existent value
    • mod_admin_shell: Add role:list() and role:show() commands
    • MUC: Fix nickname registration form error handling ( #1930 )
    • MUC: Fix Error when join stanza sent without resource ( #1934 )
    • MUC: Factor out identification of join stanza
    • mod_invites_register: Don’t restrict username for roster invites (thanks lissine)
    • mod_admin_shell: Fix matching logic in s2s:close (Thanks Menel)
    • mod_authz_internal: Improve error message when invalid role specified
    • mod_http_file_share: Add media-src ‘self’ to Content-Security-Policy header
    • mod_admin_shell: Visual tweaks to the output of debug:cert_index()
    • mod_http: Log problems parsing IP addresses in X-Forwarded-For (Thanks Boris)
    • mod_http: Fix IP address normalization (Thanks Boris)
    • util.prosodyctl.check: Improve reporting of DNS lookup problems

    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!

    • wifi_tethering open_in_new

      This post is public

      blog.prosody.im /prosody-13.0.2-released/

    • chevron_right

      Erlang Solutions: The Importance of Digital Wallet Security

      news.movim.eu / PlanetJabber • 28 May • 6 minutes

    Digital wallets have transformed how people pay and how businesses get paid. With more consumers choosing contactless and mobile transactions, offering these payment options is part of staying relevant.

    That’s why your business needs to understand digital wallet security – how it works, where the risks lie, and what it takes to protect customer data and payment information.

    In this guide, we’ll walk through how digital wallets function, the benefits they offer, and why security needs to be a central part of any payment strategy.

    Why digital wallet security is important

    You likely already have some understanding of the importance of digital wallet security. But the scale of risk today makes it worth revisiting.

    In 2024, scammers stole $494 million in cryptocurrency through wallet-draining attacks, according to BleepingComputer . These attacks hit over 300,000 wallet addresses, a 67% jump in stolen funds compared to the year before. The number of victims? Up just 3.7%. That means attackers are going after (and reaching) higher-value targets.

    And it’s not just about crypto. IBM reports that the average cost of a data breach globally is now $4.45 million , up 15% in just three years. For any business handling payments or user data, it’s a direct, growing risk. Understanding how digital wallets work and how to secure them is quickly becoming part of the baseline for doing business responsibly.

    What is a digital wallet?

    A digital wallet is a software-based tool that stores payment information securely on a smartphone or similar device. It allows customers to pay online or in-store without needing to enter card details or carry cash.

    For businesses, it’s a shift in how people expect to transact. Digital wallets offer speed at the till, fewer failed payments, and a smoother customer experience.

    More than just payments

    Digital wallets do more than handle payments. Many store loyalty cards, ID, tickets, and even crypto. Some link to bank accounts, others work with preloaded funds.

    Services like Apple Pay and Google Pay are already woven into consumers’ everyday lives, helping drive adoption. According to Grandview research, the global mobile wallet market reached USD 7.42 billion in 2022, and it’s expected to grow 28.3% annually through 2030, fuelled by smartphone use, internet access and booming e-commerce.

    Source: Grandview Mobile Market research

    Security is built in from the start

    While we’ve touched on the fact that attacks and risks exist, digital wallets are inherently designed with security as a top priority.

    What makes digital wallets valuable and viable is the level of built-in protection. Strong digital wallet security is a core feature, not an add-on. Encryption, tokenisation, and biometric authentication all help reduce fraud and protect customer data. The UK market is catching on fast. According to Worldpay, digital wallets are expected to handle over £200 billion in e-commerce transactions by 2027 . This shift in consumer behaviour is here to stay. So ask yourself if your payment strategy is keeping up the pace.

    How do digital wallets work?

    Digital wallets use a mix of mobile technology and built-in security to make payments quick and easy. Whether customers are shopping online or tapping their phone in person, there’s no need to enter card details every time.

    The process starts with a secure app or platform. Once a user adds their card and verifies their identity, typically using a fingerprint, face scan or PIN, the wallet is ready to use.

    For in-store payments, the customer unlocks their phone, chooses a card, and holds the device close to the payment terminal. For online purchases, they simply select the wallet at checkout and approve the payment on their device.

    Key tech behind digital wallets:

    • Near-field communication (NFC):
      The most common method for contactless payments. NFC allows smartphones, smartwatches and compatible cards to securely exchange payment data with terminals by holding the device a few centimetres away with no physical contact needed.
    • Magnetic secure transmission (MST):
      MST mimics the magnetic stripe on traditional cards by emitting an encrypted signal. It’s less common than NFC but still supported by some wallets and terminals.
    • QR codes:
      Used more often in markets where contactless readers aren’t standard, QR codes allow customers to scan and pay using a barcode displayed on-screen.

    Once the payment is sent, the point-of-sale system routes the data to the payment processor. From there, it goes through the standard authorisation process with the customer’s bank.

    Are digital wallets safe?

    We’ve covered what digital wallets are and how they work. Now, let’s get into the bigger question: how secure are they?

    The risks businesses should be aware of

    We have mentioned that digital wallets are designed with strong safeguards in place, but there are still risks to be made aware of.

    These typically come from user behaviour, unsecured environments, or sophisticated cyberattacks.

    Here are some of the most common risks:

    Risk Description Impact
    Phishing scams Fake emails or messages are designed to trick users into revealing login credentials or PINs. Can lead to full access to a user’s digital wallet and financial data.
    Malware Malicious software that can be unknowingly installed on a device. Allows attackers to access stored wallet data and steal funds or identities.
    Unsecured public Wi-Fi Open networks that allow hackers to intercept data being transmitted. Sensitive financial information can be captured during transactions.
    Device loss or theft Stolen or misplaced smartphones or tablets containing digital wallet access. If not secured properly, attackers could gain direct access to stored financial information.
    Data breaches & hacking Cybercriminals target servers or systems where digital wallets are used or managed. Can expose large volumes of user data, including transaction history and account credentials.
    Phishing & social engineering Deceptive tactics are designed to manipulate users into revealing private information. Still, the leading cause of data breaches, despite increased awareness and training.

    How to use digital wallets safely

    If your business offers or accepts digital wallet payments, security is key to safeguarding your customers and protecting your reputation. With the right steps, keeping digital payments secure can be simple.

    Here are some best practices businesses and their customers should follow and encourage to make digital wallet use safer:

    • Use strong, unique passwords
      Avoid easy or repeated passwords across accounts. Encourage users to choose complex combinations that aren’t reused elsewhere.
    • Enable biometric authentication
      Fingerprint or facial recognition adds an extra layer of protection beyond passwords and PINs.
    • Keep software updated
      Regular updates patch security holes in your device’s operating system and digital wallet apps, reducing vulnerability to attacks.
    • Separate social media and financial apps
      Using different devices or accounts for social and financial activities can lower the risk of cross-app attacks or data leaks.
    • Be vigilant about phishing
      Train teams to recognise suspicious emails or messages that try to steal login details. Remind customers not to click on unknown links.

    Many digital wallets come with built-in security features, including:

    • Encryption and tokenisation
      These turn sensitive payment details into unreadable codes or tokens for each transaction, making data breaches far less damaging.
    • Two-factor authentication (2FA)
      Requiring two forms of verification before access helps ensure only authorised users can make payments.
    • Fraud monitoring
      Some wallets automatically flag or block suspicious activity to prevent unauthorised transactions.

    In industries such as telecomms, banking and fintech, developers often rely on secure, reliable programming languages such as Erlang and Elixir to build payment systems that can handle high volumes without compromising security.

    These technologies help ensure digital wallets remain both fast and safe for everyday business use.

    To conclude

    For businesses, digital wallet security is essential for protecting both customers and reputation. Digital wallets include strong built-in protections, but knowing the risks and how to address them helps keep your business and customers safe.

    By focusing on security, you create a safer payment environment and earn customer trust. As digital wallets become a standard payment option, staying informed and prepared will keep your business competitive and secure. Ready to discuss strengthening your payment security? Get in touch.

    The post The Importance of Digital Wallet Security appeared first on Erlang Solutions .

    • wifi_tethering open_in_new

      This post is public

      www.erlang-solutions.com /blog/the-importance-of-digital-wallet-security/

    • chevron_right

      Erlang Solutions: Common MVP mistakes: How to build smart without overbuilding

      news.movim.eu / PlanetJabber • 13 May • 5 minutes

    A Minimum Viable Product (MVP) is your first real signal to the market, your team, and your investors that you’re solving the right problem in the right way. While it’s often mentioned alongside terms like Proof-of-Concept (PoC), prototype, or pilot, an MVP plays a distinct role: validating real value with real users.

    Avoiding common missteps early sets the stage for faster iteration, smarter growth, and long-term success. Startups are under pressure to move quickly, but speed without focus can lead to costly mistakes. Proving value fast is essential, especially with limited resources, but moving too quickly without the right foundation can stall progress just as easily as moving too slowly.

    What an MVP should be

    An MVP is the leanest version of your product that still delivers real value and helps you learn whether you’re solving the right problem.

    It’s not about perfection, but validation. Will users care enough to try, pay, or share?

    Importantly, a strong MVP also signals to investors that you can efficiently test ideas, understand your market, and move fast with limited resources.

    Focus on what matters, build with intent, and treat your MVP not as a throwaway prototype, but as the foundation of everything to come.

    Small by design, smart by strategy

    Popularised by Eric Ries in The Lean Startup , the MVP is designed to reduce wasted time, money, and effort. By building only what’s needed to test your core assumptions, you can learn quickly and adjust early, before burning through too much time, money, or energy.

    A good MVP doesn’t just mean “basic”

    A strong MVP isn’t just a stripped-down prototype. It’s the foundation of your product. Lightweight, but also reliable, secure, and built for change. If it can’t be used, demoed, or trusted, it’s not doing its job.

    Focus on what matters, build with intent, and treat your MVP not as a throwaway prototype, but as the foundation of everything to come.

    Minimise risk, maximise learning

    An MVP helps you move fast and stay focused. It’s not about trial and error. It’s about proving your idea works and showing investors that you’re building something ready to grow.

    Common MVP mistakes (and how to avoid them)

    Building an MVP is about speed and learning. But moving fast shouldn’t mean skipping the fundamentals. Many startups fall into familiar traps: doing too much too soon, choosing the wrong tools, or cutting corners that cause problems later.

    By spotting these mistakes early, you can build smarter, avoid rework, and give your product a better chance of success.

    Overbuilding Before Validation

    Adding too many features at the start slows you down, increases costs, and weakens your core value. A bloated MVP is harder to test, more expensive to maintain, and often confusing for users.

    Why it happens:

    • Unclear priorities
    • Perfectionism
    • Fear of missing out

    How to avoid it:

    Focus on solving one clear problem well. Use low-code or no-code tools to test ideas quickly without overcommitting time or budget.

    Choosing the wrong tech stack

    Selecting technology based on trends instead of fit creates long-term issues. The wrong stack can lead to expensive rebuilds, poor stability, development slowdowns, and scaling challenges.

    Why it matters:

    Your tech choices affect how fast you can iterate, how well you scale, and how easy it is to adapt later.

    How to avoid it:

    Choose a simple, flexible stack that fits your domain. Use tools that support rapid development and long-term growth. Involve technical partners or advisors with experience to help avoid common mistakes.

    Ignoring security and code quality

    When speed trumps structure, the result is often messy, unreliable code.

    A growing trend, vibe coding , uses AI (especially large language models) to quickly generate code from natural language. While this accelerates initial progress, it often skips testing, documentation, and consistency, leading to hidden risks and technical debt.

    Though fast at first, vibe coding can leave fragile code that’s hard to debug, extend, or transfer, with teams diverging in approach and progress stalling over time.

    Why does it happen?

    • Misunderstanding MVP as “low quality” rather than “focused and efficient”
    • Overreliance on AI-generated code without review or standards
    • Lack of experienced engineering oversight

    Risks include:

    • System instability and hidden failures
    • Security vulnerabilities and compliance breaches
    • Technical debt and poor maintainability
    • Loss of trust from investors and partners

    How to avoid it:

    Prioritise quality from day one:

    • Review AI code for security, clarity, and maintainability
    • Apply secure authentication and data encryption
    • Set shared coding standards and style guides
    • Require basic tests and documentation, even for MVPs
    • Limit LLM use in critical paths unless thoroughly validated
    • Track shortcuts and log them as technical debt to resolve later

    A little rigour early on prevents major setbacks down the line.

    What smart MVP development looks like

    A smart MVP is fast, focused, and built for flexibility. It doesn’t aim to include everything, just enough to test your core idea with real users.

    Here’s what that looks like in practice:

    Built fast, not rushed

    Speed should serve as validation. The best MVPs reach users quickly without creating confusion or technical debt.

    Focus on:

    • Delivering one clear value
    • Releasing early to gather feedback
    • Improving in tight, focused cycles

    Easy to change, because feedback is coming

    A smart MVP is flexible by design. Once feedback starts coming in, you need to be ready to adjust quickly without overhauling everything.

    Make this easier with:

    • Modular code
    • Clear documentation
    • A prioritised backlog for fast iteration

    Safe and secure – even if it’s lean

    Even a small MVP needs to be stable and secure. If users are testing it, they’re trusting it.

    Trust depends on:

    • Data security and privacy (including GDPR compliance)
    • A clear, usable interface
    • Consistent, reliable performance

    A strong MVP is :

    • Right-sized: Solves one problem well
    • Stable: Works reliably in demos and tests
    • Scalable: Built on a foundation that can grow
    • Trustworthy: Respects and protects user data

    Smart MVP development means building fast, but building right. When you combine speed with strategy, you don’t just ship faster, you learn faster, improve faster, and grow stronger.

    Build fast. Build smart. Build for growth.

    A strong MVP helps you validate your idea, attract early users or investors, and gather feedback, without overbuilding or overspending. The goal is not just to launch quickly, but to launch with clarity, purpose, and scalability in mind.

    Many teams fall into the same traps: bloated feature sets, the wrong technology choices, or neglecting long-term costs. These missteps waste time, burn cash, and kill momentum. The most effective MVPs are built with focus, tested against the right assumptions, and grounded in a foundation that supports growth from day one.

    At Erlang Solutions, we can help your startup launch MVPs that are resilient under pressure and built for the future. If you’re ready to build something that works, let’s talk .

    The post Common MVP mistakes: How to build smart without overbuilding appeared first on Erlang Solutions .

    • wifi_tethering open_in_new

      This post is public

      www.erlang-solutions.com /blog/common-mvp-mistakes-how-to-build-smart-without-overbuilding/

    • chevron_right

      The XMPP Standards Foundation: The XMPP Newsletter April 2025

      news.movim.eu / PlanetJabber • 5 May • 8 minutes

    XMPP Newsletter Banner

    XMPP Newsletter Banner

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

    Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom .

    XSF Announcements

    XSF Membership

    If you are interested in joining the XMPP Standards Foundation as a member, submissions are open until May 18th, 2025, 00:00 UTC! .

    XSF Fiscal Hosting Projects

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

    XMPP Events

    • Berlin XMPP Meetup [DE / EN]: monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month at 6pm local time.
    • XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming).
    • XMPP Sprint in Berlin : On Friday, 23rd, Saturday, 24th, and Sunday, 25th of May 2025.

    XMPP Articles

    XMPP Software News

    XMPP Clients and Applications

    • Cheogram has released version 2.17.10-1 for Android. This version introduces an initial implementation of Spaces ( XEP-503 ), among other improvements, bugfixes and more!
    • Conversations has released versions 2.18.0 , 2.18.1 and 2.18.2 for Android. Notable changes include the ability to pick a custom backup location, a prominent backup restore option for Quicksy , and improved support for more kinds of URIs. The latter includes tel phone numbers, mailto email addresses, and more interestingly the web+ap scheme for ActivityPub proposed by Fedi Links .
    • Dino has released version 0.5 featuring OMEMO encryption by default, improved file transfers, image preview and other file details before downloading, and two completely reworked dialogs. See the release blog post for all the details.
      • At the same time, Dino has also received funding from NLnet to begin development on a slew of new features. This includes message moderation in group chats, local message deletion, modern connection handling with FAST and SASL2, more formatting options with Message Markup, and more! Visit the project page for all the details.
    • Gajim has released versions 2.1.0 and 2.1.1 with a new ‘Activity feed’ page, layout improvements for its ‘Start Chat’ dialog and support for ‘Message Display Synchronisation’ ( XEP-0490 ) across group chats among other improvements and bugfixes. Head over to their News section for all the details.
    Activity feed in Gajim 2.1

    Activity feed in Gajim 2.1

    Account and status selection in Gajim 2.1

    Account and status selection in Gajim 2.1

    • Kaidan has received NLnet funding for various improvement across the board , most notably multi-user chat and support for legacy OMEMO. The second point is significant because while Kaidan is using a newer version of the OMEMO end-to-end encryption protocol, other popular clients including Conversations, Monal, and Dino are still using an older version. Since the two are not compatible, this meant Kaidan users were unable to use OMEMO encryption with users of most other clients. By implementing the older spec as well, Kaidan will help bridge that gap.

    • Monocles Chat 2.0.6 has been released for Android. This version brings initial support for file captions, the option to pin an unencrypted message to the top of a conversation, providers list support, and the option to register on your own XMPP server, among many other new features and improvements.

    Monocles Chat 2.0.6: Initial captions to files and pin message to the top

    Monocles Chat 2.0.6: Initial captions to files and pin message to the top

    Monocles Chat 2.0.6: Register on your own XMPP server or pick one from the providers list

    Monocles Chat 2.0.6: Register on your own XMPP server or pick one from the providers list

    • Movim has released version 0.30 (code named “ Encke ”), the biggest Movim evolution in many years! This release brings multi-participant calls , reactions being displayed in the detailed message view, support for Unicode 15.1 with plenty of new emojis to use, and avatars that change when a contact adds to their Story .
    Movim 0.30 (Encke): Multi Participant Calls. Bob Cat looking disgruntled by the presence of the ‘Hooman’ on the lower right of the screen!

    Movim 0.30 (Encke): Multi Participant Calls. Bob Cat looking disgruntled by the presence of the ‘Hooman’ on the lower right of the screen!

    Movim 0.30 (Encke): Meow OwO bedazzled by the looks of Multi Participant Calls on his mobile device!

    Movim 0.30 (Encke): Meow OwO bedazzled by the looks of Multi Participant Calls on his mobile device!

    • and following right on its heels, Movim also published its first bug-fix release: version 0.30.1 , adding animated pictures support in the image proxy and a new Avatar and Banner Configuration Panel, as well as implementing ( XEP-0392 ) Consistent Color Generation, among many other improvements and bugfixes. Make sure to check out the official announcements at the Movim Blog for all the details!
    Movim 0.30.1: Avatar and banner configuration panel

    Movim 0.30.1: Avatar and banner configuration panel

    XMPP Servers

    • MongooseIM has released version 6.3.3 of its Enterprise Instant Messaging Solution. This minor update includes various fixes and improvements. For more information, check out the documentation .
    • ProcessOne has published ejabberd 25.04 . This release brings an important security fix, several bug fixes and a new API command.
    • Prosody IM is pleased to announce version 13.0.1 , a new minor release from the latest stable branch. It fixes some important bugs that were discovered after the latest release. Read all the details on the release changelog . As always, detailed download and install instructions are available on the download page for your convenience.
    • The Prosody app for YunoHost has been updated to provide a bunch of supported XEPs by default, configured for all YunoHost users in just one click. YunoHost is a set of tools to easily manage your own selfhosted services, and while it used to come bundled with the Prosody fork Metronome by default, it has recently bundled its XMPP functionality into a separate “app” so that people can swap in any other XMPP server of their choice.

    XMPP Libraries & Tools

    Extensions and specifications

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

    Proposed

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

    • No XEPs proposed this month.

    New

    • No New XEPs this month.

    Deferred

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

    • No XEPs deferred this month.

    Updated

    • Version 1.1.3 of XEP-0313 (Message Archive Management)
      • Fixed typo (XEP Editor (dg))
    • Version 0.4.0 of XEP-0377 (Spam Reporting)
      • Add spam report processing opt-in.
      • Add Guus der Kinderen as co-author. (gdk)
    • Version 1.0.1 of XEP-0421 (Occupant identifiers for semi-anonymous MUCs)
      • Fixed typo (XEP Editor (dg))
    • Version 0.3.0 of XEP-0455 (Service Outage Status)
      • Remove all in-band event signaling. (mp)

    Last Call

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

    • No Last Call this month.

    Stable

    • No XEPs moved to Stable this month.

    Deprecated

    • No XEPs deprecated this month.

    Rejected

    • No XEPs rejected this month.

    Spread the news

    Please share the news on other networks:

    Subscribe to the monthly XMPP newsletter
    Subscribe

    Also check out our RSS Feed !

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

    Newsletter Contributors & Translations

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

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

    Help us to build the newsletter

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

    Tasks we do on a regular basis:

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

    Unsubscribe from the XMPP Newsletter

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

    License

    This newsletter is published under CC BY-SA license .

    • wifi_tethering open_in_new

      This post is public

      xmpp.org /2025/05/the-xmpp-newsletter-april-2025/