Vaccines are readily available in the US now, you can walk in to a pharmacy anywhere and get it. There is no need for the Vaxbot service (http://vaccine.monal.im) here anymore. After 11 million alerts sent out, we have shutdown US operations last week on May 8th and start focusing on Canada (where we just expanded) and likely add the EU (or anywhere else in the world that needs help) next.

Thanks to everyone on the Monal and the server administrators and developers from Yaxim and Prosody teams for making this project a success! We’ve made a difference in the lives of thousands of people and there is still much more to do.

If you are still interested in the open and free technology behind Vaxbot, please take a look at Monal IM which is the main project which enabled the simple setup of Vaxbot.

RabbitMQ, the message broker, is not the first thing that comes to mind when we talk about integrating legacy services. We use high level frameworks to hide the complexity of the underlying plumbing. In this post we will show how the RabbitMQ, the most widely deployed open source message broker, can help with reliable and resilient messaging.

What is RabbitMQ?

RabbitMQ is a free, open-source and extensible message queuing solution. It is a message broker that understands AMQP (Advanced Message Queuing Protocol), but can also be used with other popular messaging solutions like MQTT. It is highly available, fault tolerant and scalable. It is implemented in Erlang OTP, a technology tailored for building stable, reliable, fault tolerant and highly scalable systems which possess native capabilities of handling very large numbers of concurrent operations. The benefits of Erlang OTP can easily be seen in RabbitMQ and other systems like WhatsApp, MongooseIM, to mention a few.

At a very high level, it is a middleware layer that enables different services in your application to communicate with each other without worrying about message loss while providing different quality of service (QoS) requirements. It also enables fine-grained and efficient message routing enabling extensive decoupling of applications.

RabbitMQ Connecting Legacy Services

When designing system interactions we usually start with a top-to-bottom approach. We identify the components and use the technology available to connect them. If we need to integrate existing systems with newer ones, then it is often infeasible to change the older system to use modern protocols. In cases like this, connector applications can be developed acting as a bridge between the old system and the new.

Once we know the components and we have all the translation layers, we can deal with the interconnection. There are two major ways how parts of the system can communicate:

1. Directly (synchronously). When both components are online, they can use an active network connection and a preferred protocol like HTTP, protobuf or even FTP. Using these technologies results in a simple solution with its trade-offs, such as unavailability of multiple services, or having to implement client side buffering, when things go wrong.
2. Indirectly (asynchronously). To mitigate the trade-offs from the direct communication we can introduce a messaging layer into the solution that can retain the messages even if the receiving application is not online. Although this adds complexity to the architecture it removes a lot of edge cases from the applications. Scaling the messaging layer is often easier than introducing scale to the legacy applications.

RabbitMQ is a well-suited message broker because it scales well not only with the message load requirements, but also with the business requirements. Finding message brokers that can handle hundreds or thousands or even tens of thousands of messages is easy. But finding a message bus that can cater for several messaging patterns, can handle different protocols (AMQP, MQTT, STOMP, JMS and many more) and can be modified via plugins is much more difficult.

Features come with trade-offs, but when RabbitMQ is put into a heterogeneous environment, it provides an easy way to move the messages between virtually any systems. All major frameworks support an AMQP adapter, but even if the component uses a proprietary protocol then it is possible to develop a plugin and extend RabbitMQ’s functionality.

Hear from industry leaders at RabbitMQ Summit 2021

Resilient and Reliable Messaging

RabbitMQ provides a high degree of availability and consistent messaging if the following three features are used. First we see why it is recommended to run RabbitMQ as a cluster, then how to guarantee that messages are received and kept safe by RabbitMQ and how quorum queues improve on classic mirroring.

Clustering

Although a single node RabbitMQ provides the highest consistency guarantees, it is not resilient to hardware errors or planned downtimes due to upgrades. If anything happens to the single RabbitMQ instance it means that the service is no longer available system-wide. If any of the message store files gets corrupted on the file system, then messages can be lost.

To avoid these problems RabbitMQ can run as a cluster, each node providing the full RabbitMQ functionality. It does not matter for the clients which RabbitMQ node it connects, RabbitMQ hides the complexities of distributing and replicating messages, queues and exchanges.

The big question is how many nodes we should use in a cluster. Using two nodes might be tempting, but it only works with systems running in an active-passive nature. RabbitMQ, as we discussed above, runs in an active-active fashion where each node in a cluster provides identical functionality. This means that in case of any problems, RabbitMQ needs a consensus of the majority of the nodes to function. By restricting the number of nodes in a cluster to an odd number, we can guarantee that the cluster will consistently survive the loss of the minority of the nodes (in case of 5 nodes, RabbitMQ can tolerate the loss of 2 nodes.)

To enforce that the minority nodes don’t commit changes, pausing them when detecting a network issue can be automated by setting the cluster partition handling mechanism to pause_minority. This is a built-in feature and it not only detects that a network partition occurred but also detects when the network is working again and can restart the nodes paused automatically. RabbitMQ does not require manual intervention to heal.

Publisher confirm and acknowledgements

RabbitMQ can automagically cluster and heal itself, but due to the distributed nature of things, it requires some cooperation from the clients to guarantee no message loss. When publishing a message to RabbitMQ the clients can only “forget” about the message when it was acknowledged by RabbitMQ. This acknowledgement on the publishing side is called the Publisher Confirm feature. It is more lightweight than the transaction mechanism in AMQP and performs much better under load. This RabbitMQ specific feature is supported by all major client libraries.

On the consuming side, the clients should acknowledge the message only when they finished processing the message. This guarantees that once a message is fully processed it is removed from RabbitMQ, but if any problem happens during message processing, the same message can be redelivered to the same or a different client. This gives a good opportunity to introduce horizontal scaling for parts of the system.

Quorum Queues

The last bit of the puzzle is to make sure that the messages that are in RabbitMQ can survive network errors, hardware failures or planned maintenance. With the introduction of clustering it is possible to distribute the workload among many nodes, but it is also important for introducing resiliency. Quorum queues are the new addition to the RabbitMQ feature family providing an improved solution to queue mirroring. It is based on the state of the art Raft algorithm to manage the integrity of the queue leader and the contents of the queues. Using it together with the publisher confirms, it is guaranteed that messages acknowledged by RabbitMQ will be safe until they are delivered to consumers.

Quorum queues improve on one of the major issues of classic queue mirroring: queue synchronisation after a network partition. With the Raft protocol, it is possible to only copy the messages that are missing from the mirror. This reduces the synchronisation network pressure which was a cause for some hard-to-debug RabbitMQ issues in the past.

Summary

In this blogpost, we discussed the major challenges of integrating legacy and non-legacy systems. Introducing a versatile messaging layer like RabbitMQ can provide solutions to lots of problems and applying the three major features highlighted in this blogpost will enable a successful project.

Here at Erlang Solutions, have world leading experts in RabbitMQ and can help with finding solutions to the unique problems of distributed systems. These challenges range from auditing the planned or deployed RabbitMQ solution or designing bespoke solutions with RabbitMQ. Get in touch to find out more about how we can help with your integration project.

The post How to use RabbitMQ in service integration appeared first on Erlang Solutions.

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

This release addresses a number of important security issues that affect most deployments of Prosody. Full details are available in a separate security advisory. We recommend that all deployments upgrade or apply the mitigations described in the advisory.

Note: We have updated the default config file. Your package manager may warn you about this, and ask if you want to use the new file or keep your existing one. You should usually keep your existing one, but make sure you update it to enable mod_limits after the upgrade.

A summary of changes in this release:

Security

• mod_limits, prosody.cfg.lua: Enable rate limits by default
• certmanager: Disable renegotiation by default
• mod_proxy65: Restrict access to local c2s connections by default
• util.startup: Set more aggressive defaults for GC
• mod_c2s, mod_s2s, mod_component, mod_bosh, mod_websockets: Set default stanza size limits
• mod_authinternal{plain,hashed}: Use constant-time string comparison for secrets
• mod_dialback: Remove dialback-without-dialback feature
• mod_dialback: Use constant-time comparison with hmac

Minor changes

• util.hashes: Add constant-time string comparison (binding to CRYPTO_memcmp)
• mod_c2s: Don’t throw errors in async code when connections are gone
• mod_c2s: Fix traceback in session close when conn is nil
• core.certmanager: Improve detection of LuaSec/OpenSSL capabilities
• mod_saslauth: Use a defined SASL error
• MUC: Add support for advertising muc#roomconfig_allowinvites in room disco#info
• mod_saslauth: Don’t throw errors in async code when connections are gone
• mod_pep: Advertise base pubsub feature (fixes #1632: mod_pep missing pubsub feature in disco)
• prosodyctl check config: Add ‘gc’ to list of global options
• prosodyctl about: Report libexpat version if known
• util.xmppstream: Add API to dynamically configure the stanza size limit for a stream
• util.set: Add is_set() to test if an object is a set
• mod_http: Skip IP resolution in non-proxied case
• mod_c2s: Log about missing conn on async state changes
• util.xmppstream: Reduce internal default xmppstream limit to 1MB

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!

This two-part blog series looks at the jobs to be done in fintech and argues that the right tool for the job, the Erlang/Elixir/OTP open-source ecosystem for software development, has its roots in telecom – an industry that has already resolved many of the new challenges confronting fintech currently.

To ensure you don’t miss part two of this blog and other high-quality content from us you can subscribe to our fintech newsletter here.

The Brave New World of Fintech

The world of financial services using technology to make individuals’ lives easier and more prosperous is becoming increasingly similar to the world of telecommunications.

The simple reason is that since the introduction of the iPhone (a smart telecommunications device also known as a “smartphone”) in 2007, most of our interactions with banks and other financial institutions are through smartphones. 

This means that we expect the banking experience to be as good as all our other smartphone experiences, be it entertainment or work related, including around the clock availability and responses within fractions of a second. This is backed up by research showing that response times above half a second makes people wonder what is going on and get stressed.

Since it is about money and other financial instruments, we also expect all interactions and personal data to be highly secure from e.g. intrusions and theft. The essence of all financial services is trust. You trust banks to not lose your money. If you lose the trust in your bank, you will switch to another bank or at least move parts of your business elsewhere. 

In more technical terms, we want our financial interactions to be done in real-time and be extremely secure and reliable. 

The Job to Be Done

From a customer perspective, we have just seen how our financial services needs are for real-time, secure and reliable products and solutions. Also, we expect new innovative services that simplify our daily lives, e.g. saving us time and money while growing our financial wealth. One example is instant payments using your smartphone as a digital wallet connected to your bank account where work is ongoing to enable instant person-to-person payments also across national borders.

The traditional banks have a track record of security and reliability leading to trust, loyalty and long-standing personal relationships with their customers with e.g. personal banking experts available for financial advice. In the past that trust was established with large imposing buildings signifying they were here to stay.  Over time banks have eliminated buildings – particularly in the branch network in order to reduce costs and as a consequence “trust” has become more intangible. 

As a traditional bank, you would like to extend the experience to the digital world and at the same time reduce your large cost base which is due to very old hardware and software.  One example is a European bank that developed a new, well-designed and innovative smartphone application that unfortunately did not work since it took up to 30 seconds to fetch customer data from the legacy software system. They realised that their legacy software system was not fit for the future and have since then started to replace the system with future-proof technology, one “elephant carpaccio slice” at a time.

If you are a startup providing financial services, your needs are your customers’ needs, so real-time, security and reliability in order to secure their trust and loyalty are still valid. Since you are competing with the incumbent giants, you need a unique, focused offering that can be developed quickly and operated at low cost. Additionally, you want to provide a smooth onboarding experience to acquire new customers quickly. Backbase and Tide offer one minute customer onboarding time, a process that usually requires at least 48 hours to fully vet and comply with regulations. 

If you are one of the big US technology giants, you may want to consider your particular superpower, e.g. social networking, superb user experience or superior customer understanding, to expand your offering to embrace selected financial services as an integral part of your brand. One example is Apple Pay which extends the real time facility without having a current account or complying with onboarding requirements. Another example is Uber Money with digital wallets and credit and debit cards.

If you are one of the clearing houses, banking centrals, credit card companies or central banks, the huge number of financial transactions due to the real-time interactions lead to massive requirements on scalability and resilience of your technical infrastructure since the systems you operate are critical, not only for your specific customers but for society at large. We are seeing experiments with digital currencies run by several central banks in the world, including Sweden’s “Riksbank”, founded in 1668.

If you are one of the providers of digital currencies based on blockchain technologies you also face the challenge of minimising the energy consumption for all the computations needed.

Considering the engineers and developers who design, deliver and operate the financial systems, they want an environment where you can develop and deploy easily – including smooth programming languages requiring few lines of code supported by libraries, frameworks and tooling – and get quick feedback from both development, test and commercial deployments. Motivated and engaged employees lead to better services and happier and more loyal customers.

To summarise: we need real-time, secure, reliable and scalable systems that can be developed quickly and smoothly, operating at low cost with interoperability across borders and currencies.

FinTech Trends in 2021 Report

The Telecoms World

Fortunately, the needs of real-time, secure, reliable, scalable and interoperable systems that can be developed quickly and operated at low cost have already been fulfilled in the telecoms world starting in the 60s and 70s when the telecom operators started deploying the first digital software switches for local, regional and international phone calls. This infrastructure critical for society was designed, developed and tested for global, real-time around the clock operation with billions of users from the very beginning and global standards for interoperability were key enablers. 

The technology evolution grew very rapidly in the 80s and 90s due to the increased demands for communication on the move using handsets connected to mobile networks, first using national network standards  (the first generation, 1G, for voice calls only), then regional network standards (the second generation, 2G, for voice, text messages and limited data transmission), and, finally global network standards (the 3rd, 4th and 5th generations, 3G/4G/5G, optimised for higher and higher rates of data transmission).

This evolution happened in parallel with the evolution of systems for secure and reliable financial transactions. The biggest difference was that the telecom systems had far more transactions to handle due to the real-time nature of phone calls, mobile phone calls and browsing the web whereas the financial world handled this particular challenge through daily batches around midnight where all the financial transactions during the past 24 hours were processed.

Finally, telecoms have been commoditised by regulation, standards and global competition and is now a low margin business. There is a similar threat to financial services. In telecom, threats such as Google and others were well known to telecoms yet the telecom operators failed to act and now the value has been taken by the Big US Tech players with a global mindset. 

To summarise, telecoms have already mastered the challenge of real-time, secure, reliable, scalable and interoperable systems that can be developed quickly and operated at low cost. At Erlang Solutions we believe that a lot of our learnings from this industry can be applied to exciting new projects in the fintech space. 

Writer

Erik Schön, Managing Director, Erlang Solutions Nordic, is an executive with 20+ years of telecoms experience from global standardisation, system design and managing R&D organisations of up to 400 people at the global telecom giant Ericsson. Erik is a big fan of Erlang since the 90s and his latest book is The Art of Strategy.

For part two of this blog series and other great fintech content you can subscribe to our newsletter here.

The post Lessons FinTech Can Learn From Telecom – Part One appeared first on Erlang Solutions.

This blog post looks at the jobs to be done in fintech and argues that the right tool for the job, the Erlang/Elixir/OTP open-source ecosystem for software development, has its roots in telecom – an industry that has already resolved many of the new challenges confronting fintech currently.

The Brave New World of Fintech

The world of financial services using technology to make individuals’ lives easier and more prosperous is becoming increasingly similar to the world of telecommunications.

The simple reason is that since the introduction of the iPhone (a smart telecommunications device also known as a “smartphone”) in 2007, most of our interactions with banks and other financial institutions are through smartphones. 

This means that we expect the banking experience to be as good as all our other smartphone experiences, be it entertainment or work related, including around the clock availability and responses within fractions of a second. This is backed up by research showing that response times above half a second makes people wonder what is going on and get stressed.

Since it is about money and other financial instruments, we also expect all interactions and personal data to be highly secure from e.g. intrusions and theft. The essence of all financial services is trust. You trust banks to not lose your money. If you lose the trust in your bank, you will switch to another bank or at least move parts of your business elsewhere. 

In more technical terms, we want our financial interactions to be done in real-time and be extremely secure and reliable. 

The Job to Be Done

From a customer perspective, we have just seen how our financial services needs are for real-time, secure and reliable products and solutions. Also, we expect new innovative services that simplify our daily lives, e.g. saving us time and money while growing our financial wealth. One example is instant payments using your smartphone as a digital wallet connected to your bank account where work is ongoing to enable instant person-to-person payments also across national borders.

The traditional banks have a track record of security and reliability leading to trust, loyalty and long-standing personal relationships with their customers with e.g. personal banking experts available for financial advice. In the past that trust was established with large imposing buildings signifying they were here to stay.  Over time banks have eliminated buildings – particularly in the branch network in order to reduce costs and as a consequence “trust” has become more intangible. 

As a traditional bank, you would like to extend the experience to the digital world and at the same time reduce your large cost base which is due to very old hardware and software.  One example is a European bank that developed a new, well-designed and innovative smartphone application that unfortunately did not work since it took up to 30 seconds to fetch customer data from the legacy software system. They realised that their legacy software system was not fit for the future and have since then started to replace the system with future-proof technology, one “elephant carpaccio slice” at a time.

If you are a startup providing financial services, your needs are your customers’ needs, so real-time, security and reliability in order to secure their trust and loyalty are still valid. Since you are competing with the incumbent giants, you need a unique, focused offering that can be developed quickly and operated at low cost. Additionally, you want to provide a smooth onboarding experience to acquire new customers quickly. Backbase and Tide offer one minute customer onboarding time, a process that usually requires at least 48 hours to fully vet and comply with regulations. 

If you are one of the big US technology giants, you may want to consider your particular superpower, e.g. social networking, superb user experience or superior customer understanding, to expand your offering to embrace selected financial services as an integral part of your brand. One example is Apple Pay which extends the real time facility without having a current account or complying with onboarding requirements. Another example is Uber Money with digital wallets and credit and debit cards.

If you are one of the clearing houses, banking centrals, credit card companies or central banks, the huge number of financial transactions due to the real-time interactions lead to massive requirements on scalability and resilience of your technical infrastructure since the systems you operate are critical, not only for your specific customers but for society at large. We are seeing experiments with digital currencies run by several central banks in the world, including Sweden’s “Riksbank”, founded in 1668.

If you are one of the providers of digital currencies based on blockchain technologies you also face the challenge of minimising the energy consumption for all the computations needed.

Considering the engineers and developers who design, deliver and operate the financial systems, they want an environment where you can develop and deploy easily – including smooth programming languages requiring few lines of code supported by libraries, frameworks and tooling – and get quick feedback from both development, test and commercial deployments. Motivated and engaged employees lead to better services and happier and more loyal customers.

To summarise: we need real-time, secure, reliable and scalable systems that can be developed quickly and smoothly, operating at low cost with interoperability across borders and currencies.

The Telecoms World

Fortunately, the needs of real-time, secure, reliable, scalable and interoperable systems that can be developed quickly and operated at low cost have already been fulfilled in the telecoms world starting in the 60s and 70s when the telecom operators started deploying the first digital software switches for local, regional and international phone calls. This infrastructure critical for society was designed, developed and tested for global, real-time around the clock operation with billions of users from the very beginning and global standards for interoperability were key enablers. 

The technology evolution grew very rapidly in the 80s and 90s due to the increased demands for communication on the move using handsets connected to mobile networks, first using national network standards  (the first generation, 1G, for voice calls only), then regional network standards (the second generation, 2G, for voice, text messages and limited data transmission), and, finally global network standards (the 3rd, 4th and 5th generations, 3G/4G/5G, optimised for higher and higher rates of data transmission).

This evolution happened in parallel with the evolution of systems for secure and reliable financial transactions. The biggest difference was that the telecom systems had far more transactions to handle due to the real-time nature of phone calls, mobile phone calls and browsing the web whereas the financial world handled this particular challenge through daily batches around midnight where all the financial transactions during the past 24 hours were processed.

Finally, telecoms have been commoditised by regulation, standards and global competition and is now a low margin business. There is a similar threat to financial services. In telecom, threats such as 9Google and others were well known to telecoms yet the telecom operators failed to act and now the value has been taken by the Big US Tech players with a global mindset. 

To summarise, telecoms have already mastered the challenge of real-time, secure, reliable, scalable and interoperable systems that can be developed quickly and operated at low cost. At Erlang Solutions we believe that a lot of our learnings from this industry can be applied to exciting new projects in the fintech space. 

The Right Tool for the Job

One of the most important tools in the telecoms toolbox for real-time, secure, reliable, scalable and interoperable systems that can be developed quickly and operated at low cost, is the open-source programming language and associated frameworks, tools and libraries called Erlang/OTP (Open Telecom Platform) originally developed by the telecom giant Ericsson.

The Need: Quick Development of the Right Thing

Mike Williams, co-creator of Erlang/OTP, wrote down his credo in 1985 which was then used to guide the development of Erlang/OTP during the 80s and 90s (Däcker, 2009):

• “Find the right methods – design by prototyping.”
• “Make mistakes on a small scale – not in a production project.”
• “It’s not good enough to have ideas – you must also be able to implement them to know that they work.”

These insights contributed to making Erlang/OTP suitable for iterative, incremental development with quick feedback from real customers. This also ensured a smooth developer experience making it easier to build the right thing that: 

• customers find valuable, usable and sometimes even desirable; 
• is feasible from a technical perspective; 
• is viable from a commercial perspective;
• is reasonable from a societal perspective, e.g. sustainable and ethical.

The Need: Real-Time, Secure, Reliable and Scalable Solutions 

Bjarne Däcker, head of the Ericsson computer science lab and Mike Williams’s manager at the time, formulated the requirements on the new programming language system as follows (Däcker, 2000):

• Real-time:  “Actions to be performed at a certain point in time or within a certain time.”
• Security: “Stringent quality”
• Reliability: “Very large software systems … Interaction with hardware … Complex functionality such as feature interaction … Continuous operation for many years … Software maintenance (reconfiguration, etc.) without stopping the system … Fault tolerance both to hardware failures and software errors”
• Scalability: “Systems distributed over several computers … handling of a very large number of concurrent activities.”

Joe Armstrong, co-creator of Erlang/OTP summarised it as “making reliable distributed systems in the presence of software errors”. (Armstrong, 2003).

Business Outcomes: Faster, Safer, Better, and, More for Less

Over the past 20+ years Erlang/OTP has provided the following business outcomes (Cesarini, 2019):

• 2x FASTER development of new services thanks to the language’s design, the OTP middleware, the set of frameworks, principles, and design patterns that guide and support the structure, design, implementation, and deployment where e.g. Motorola saw 4-20 times less code compared to traditional languages. 
• 10x BETTER services that are down less than 5 minutes per year thanks to built-in fault tolerance and resilience mechanisms built into the language and the OTP middleware, e.g. software upgrades and generic error handling, as seen by e.g. Ericsson in their mobile network packet routers.
• 10x SAFER services that are hard to hack and crash through denial of service attacks thanks to the language construction with lack of pointers, use of messages instead of shared memory and immutable state rather than variable assignments, as seen by the number of vulnerabilities compared to other languages (CVE, 2021).
• 10x MORE users (billions), transactions per second (millions) within milliseconds thanks to a battle-tested virtual machine as seen by e.g. WhatsApp with more than 2 billion users.
• 10x LESS costs and energy consumption thanks to fewer servers needed where e.g. Bleacher Report were able to reduce their hardware requirements from 150 servers to 5.

It has been used in telecom since the 90s by e.g.

• Vendors: Cisco, Ericsson, Nokia, Motorola, 2600Hz
• Operators: T-Mobile, Telia
• Social: WhatsApp

and in fintech since the mid-00s by e.g.

• Startups: Rocker, Monara
• Scaleups: Solarisbank, Brex, SumUp, Kivra
• Unicorns: Klarna
• Traditional banks and financial institutions: Mastercard, Goldman Sachs, Bloomberg, OTP Bank
• Digital currencies: æternity, BlockFi

Robert Virding, co-creator of Erlang/OTP formulated the unique value proposition like this:
“Any sufficiently complicated concurrent program in another language [for this job to be done] contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.” (Virding, 2008).

What about Elixir? 

Elixir has all the benefits of Erlang with a lower threshold for developers used to traditional programming languages like Ruby since Elixir’s syntax looks much more familiar to them. Additionally, Elixir gives a very smooth developer experience including state-of-the-art libraries e.g. for graphical user interfaces with Phoenix LiveView.

The Developer Experience

Both Erlang and Elixir are easy to learn within a couple of weeks for people with practical experiences and skills equivalent to a computer science degree as well as a curiosity to learn. And, experience shows that they get up to speed within a couple of months which is what it normally takes to understand a new product codebase or business domain (Däcker, 2000).

Engineers and developers love the experience of using Elixir and Erlang, and as of today, there are over 50,000 members in over 140 Meetup groups in all continents of the world except Antarctica (Schön, 2021). 

The Road Ahead

The Erlang/Elixir open-source ecosystem is thriving like never before.

During 2020-2021 we have seen companies like WhatsApp and Klarna working together on improving the developer experience further and companies like Ericsson evolving the OTP middleware where the next OTP release in May, 2021 is expected to improve the out-of-the-box performance of Erlang and Elixir applications by 30-130% (Larsson, 2020) and reduce the energy consumption by 25% (Cathcart, 2021).

And, we haven’t even mentioned the recent and exciting announcement of Elixir optimised for quick development of safe machine learning solutions for new innovative, automated services (Valim, 2021).

Conclusion

We hope that you now see what fintech can learn from telecom and how fintech companies can use the Erlang/Elixir/OTP open-source ecosystem to go 2x FASTER, 10x SAFER, 10x BETTER with 10x MORE for 10x LESS – resulting in happy and loyal customers as well as engaged developers.

What are your jobs to be done? What tools are you using? How can we help?

Acknowledgements

Kudos to Michael Jaiyeola, for the original idea, helpful pointers, examples and feedback; Noman Azim, for valuable input and concrete examples; Steve Roberts for helpful feedback, insights and examples from a telecom perspective; Phil Harrison for insights and feedback from a fintech perspective; Francesco Cesarini for co-creating a generous and welcoming community, for spreading the word and feedback; Joe Armstrong, Robert Virding, Mike Williams and Bjarne Däcker for perseverance, professionalism and respect in co-creating and managing Erlang/OTP.

Writer

Erik Schön, Managing Director, Erlang Solutions Nordic, is an executive with 20+ years of telecoms experience from global standardisation, system design and managing R&D organisations of up to 400 people at the global telecom giant Ericsson. Erik is a big fan of Erlang since the 90s and his latest book is The Art of Strategy.

References

Armstrong, Joe (2003). Making reliable distributed systems in the presence of software errors

Cathcart, Will (2021), Improving WhatsApp’s server efficiency by 25%

Cesarini, Francesco (2019). Which companies are using Erlang, and why? 

CVE (2021). CVE Security Vulnerability Database

Däcker, Bjarne (2000). Concurrent Functional Programming for Telecommunications: A Case Study of Technology Introduction

Däcker, Bjarne (2009). CS Lab and all that … 

Larsson, Lukas (2020). Implement BeamAsm – a JIT for Erlang/OTP.

Rubio, Manuel (2019). Which companies are using Elixir, and why?

Schön, Erik (2021). Elixir & Erlang Developers

Valim, José (2021). Nx (Numerical Elixir) is now publicly available.Virding, Robert (2008). Virding’s First Rule of Programming

The post Lessons FinTech Can Learn From Telecom appeared first on Erlang Solutions.

And now for something completely different: a rollicking discussion on the Big Yellow Praxis podcast about some underappreciated musical recordings, in which Jacob and I explore the age-old question: what exactly makes a concept album? Check it out on YouTube!...

Welcome to the XMPP Newsletter covering the month of April 2021.

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, especially throughout the current situation, please consider to say thanks or help these projects!

Read this Newsletter via our RSS Feed!

Interested in supporting the Newsletter team? Read more at the bottom! Other than that - enjoy reading!

Newsletter translations

Translations of the XMPP Newsletter will be released here (with some delay):

• French on linuxfr.org and jabberfr.org.
• The German translation currently appears at anoxinon.de
• The Italian translation of the last newsletter appeared at NicFab.it

XSF Announcement

The XMPP Standards Foundation is now on YouTube! You can find recordings of conferences, the XMPP Office Hours, and other fun stuff over on the channel.

Have a talk, demo, or roundtable discussion about XMPP or related technologies? XMPP Office Hours are weekly meetings of XMPP enthusiasts for discussion and presentations. For more information, or to sign up, have a look at the wiki page.

Events

XMPP Office Hours each week - Also, checkout our new YouTube channel!

Berlin XMPP Meetup (remote): Monthly Meeting of XMPP Enthusiasts in Berlin - always 2nd Wednesday of every month.

Articles

From May 2021, there have been major content updates for freie-messenger.de as well as additions. From now on, the content will be internationalised. As a first step, there is the new Quick Overview of Messengers in both German and English. Call for supporters!

Isode presents their military capabilities at DSEI 2021, offering Military Instant Messaging and more.

Gajim Development News: April brought an all new message styling parser, making Gajim fully compliant with XEP-0393. This post will also give you a sneak peek on some features we’ve been developing for the past months: the new Chat view and Contact Info window.

Libervia (formerly Salut à Toi) has been selected for a grant by NLNet/NGI0 Discovery Fund (with financial support from European Commission's Next Generation Internet programme) for an gateway between XMPP and ActivityPub doubled with Pubsub end-to-end encryption project. The gateway will join two major open and decentralised protocols. In practice it will be a XMPP server component (usable with any server), and implement the ActivityPub server to server protocol (or "Federation Protocol"). On XMPP side, it will be mostly a Pubsub service (with some extra, like private messages converted to XMPP message stanza).

Vaxbot continues to grow: VaxBot is a free service that helps you find vaccine appointments in your state or country if available. During the last weeks, Vaxbot continued to grow. The service just hit 8 million messages sent and it sends around 800,000 messages a day. XMPP and Vaxbot have been on TV news in Las Vegas and South Carolina, the radio in Washington as well newspapers all over the country.

Refering the Vaxbot news: Georg Lukas, who runs the server behind it, wrote an article regarding the increased subscriptions and how the services have to adapt the infrastructure to keep up with this new "VaxBot performance challenge".

Snikket announces that XMPP Account Portability was funded under the NGI DAPSI initiative. It will cover the needed standards (beyond older XEP-0227 and XEP-0238), open-source tools and integrating said functionality into Snikket.

Nicola Fabiano published an article titled: Whatsapp? No thanks, I prefer to have control over my data

Software news

Clients and applications

Conversation 2.9.11 and 2.9.12 have been released, fixing 'No Connectivity' issues on Android 7.1 and adding support for roster pre-authentication.

Gajim 1.3.2 has been released: This release brings back translations for Windows users. It also adds some small fixes and improvements.

Monal 5 Beta 4 has been released with lots of updates.

Since there appeared a lot of sendxmpp alternatives over the last years there is now an work-inprogress overview in the XSF wiki.

UWPX is replacing the SQLite-net DB backend with a new Entity Framework Core DB. This comes with a fix and update of the OMEMO implementation to the latest version of the draft (OMEMO 0.7.0 (2020-09-05)). This version is incompatible with all other previous versions of OMEMO and UWPX allows you now to only exchange OMEMO encrypted messages with contacts that support at least OMEMO 0.7.0 (2020-09-05) draft. Now UWPX can act as a client with a proper one to one OMEMO implementation!

Spark 3.0.0 Beta has been released bringing fixes as usual. Pade Meetings is now integrated (it enables audio and video chat) and all these over a complete UI refresh.

Servers

ejabberd 21.04 has been released: The new ejabberd 21.04 release includes many bugfixes and a few improvements. This release includes minor improvements to fully support Erlang/OTP 24 and Rebar3. At the same time, it maintains support back to the old Erlang/OTP 19.3 and Rebar2.

Openfire 4.6.3 has been released: This release contains a number of bug fixes and denotes the desire to provide stable 4.6.x series releases while development work continues on a 4.7.0 release.

Libraries

slixmpp 1.7.1 has been released, which is a bugfix release for a rarely used code path tied to OMEMO.

Extensions and specifications

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 have been proposed this month.

New

• Version 1.0.0 of XEP-0457 (Message Fancying)
  • This specification defines a Unicode-formatted fancy text syntax for use in instant messages.
  • Initial published version. (XEP Editor (jsc))

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 0.4.0 of XEP-0420 (Stanza Content Encryption)

  • Use 'envelope' and 'content' consistently by renaming elements Update namespace to (melvo)

• Versions 0.4.0 and 0.5.0 of XEP-0434 (Trust Messages (TM))

  • Add new section, use more precise sentences, apply consistent formatting:
  • Add new section for Trust Message URIs
  • Use 'that' instead of 'which' for restrictive clauses
  • Apply consistent formatting for paragraphs and revision history
  • Update to XEP-0420 version 0.4.0 and adapt namespace to shortname
  • Replace SCE's old 'content' element by its new 'envelope' element
  • Replace SCE's old 'payload' element by its new 'content' element
  • Update SCE's namespace to 'urn:xmpp:sce:1'
  • Change namespace to 'urn:xmpp:tm:0' (melvo)

• Versions 0.2.0 and 0.3.0 of XEP-0450 (Automatic Trust Management (ATM)

  • Add usage of Trust Message URIs, use more precise sentences, apply consistent formatting
  • Add usage of Trust Message URIs for initial authentications
  • Use 'that' instead of 'which' for restrictive clauses
  • Apply consistent formatting for paragraphs and revision history
  • Update to XEP-0420 version 0.4.0 and XEP-0434 version 0.5.0
  • Replace SCE's old 'content' element by its new 'envelope' element
  • Replace SCE's old 'payload' element by its new 'content' element
  • Update SCE's namespace to 'urn:xmpp:sce:1'
  • Update TM's namespace to 'urn:xmpp:tm:0'
  • Update namespace to 'urn:xmpp:atm:1' (melvo)

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 help improving the XEP before returning it to the Council for advancement to Draft.

• XEP-0280 Message Carbons
• XEP-0313 Message Archive Management

Draft

• No Drafts this month.

Call for Experience

A Call For Experience - like a Last Call, is an explicit call for comments, but in this case it's mostly directed at people who've implemented, and ideally deployed, the specification. The Council then votes to move it to Final.

• No Call for Experience this month.

Thanks all!

This XMPP Newsletter is produced collaboratively by the community.

Thanks to alkino, emus, Licaon_Kter, IM, Martin, mathieui, MattJ, nicola, peetah, Sam, seveso, therealjeybe, wurstsalat and Ysabeau for their help in creating it!

Spread the news!

Please share the news on "social networks":

• Mastodon
• YouTube
• Twitter
• Reddit
• LinkedIn
• Facebook

Find and place job offers in the XMPP job board.

Subscribe to receive the next edition in your inbox

Also check out our RSS Feed!

Help us to build the newsletter

We started drafting in this simple pad in parallel to our efforts in 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 write about it? Please consider sharing your news or events here, and promote it to a large audience! And even if you can only spend a few minutes of support, these would already be helpful!

Tasks which need to be done on a regular basis are for example:

• Aggregation of news in the XMPP universe
• Short formulation of news and events
• Summary of the monthly communication on extensions (XEP)
• Review of the newsletter draft
• Preparation for media images
• Translations: especially German and Spanish

License

This newsletter is published under CC BY-SA license.

My friend Paul sent me a few thoughts about my recent post on holding fewer opinions. He's formulated an approach that involves holding fewer opinions about other people's opinions. This seems valuable, and related to a post I wrote four years ago entitled "Why Do You Think What You Think?" My introspective conclusion then was that I can't always assign praise or blame for the contents of my thoughts; extending this to other people is a good example of what Arnold Kling calls cognitive empathy: instead of demonizing people who disagree with you, suspend judgment or at least try to understand where they might be coming from. (It's probably best to build up such a practice first in matters that aren't very consequential - and we all have our limits regarding the opinions we find acceptable!) The flip side is not deifying your own thoughts, which we could express in the following aphorism: "if you think well of your own opinions just because they're yours, then you're not thinking well."...

We have some exciting news to share! An important piece of the Snikket roadmap has been selected for funding by NGI DAPSI, an EU-funded project focused on data portability and services.

What is DAPSI?

The Data Portability and Services Incubator (DAPSI) is a EU funded project, under the European Commission’s Next Generation Internet (NGI) initiative. In their own words, DAPSI was established to:

[…] empower top internet innovators to develop human-centric solutions, addressing the challenge of personal data portability on the internet, as foreseen under the GDPR and make it significantly easier for citizens to have any data which is stored with one service provider transmitted directly to another provider.

You can learn more about the initiative on the NGI DAPSI website.

Data portability in Snikket and XMPP

Over the years we have seen many XMPP providers come and go, and when a provider decides to shut down, it’s too often not easy for people to obtain their data and move it elsewhere. This contributes to user churn on the XMPP network - individuals are likely to leave XMPP rather than figure out the necessary steps to migrate to a new XMPP service.

There are other reasons for wanting to move your data, such as seeking providers with better privacy or reliability. You may also want to relocate from a provider to a self-hosted solution, or vice-versa.

As part of Snikket’s mission to improve all aspects of XMPP usability, clear data ownership and portability options have been an important goal since the project’s beginning.

In particular we believe:

• People should not be locked into the service by the first provider they sign up with.
• People should be able to export their full data at any time, in a standard format.
• People should be able to easily migrate their account data to a new provider without losing important contact relationships.

The XMPP account portability project

The need for account and data portability goes beyond Snikket, we want to see improved portability and data interoperability across the whole XMPP ecosystem. DAPSI have funded an extensive project that over the next nine months will cover:

• Standardizing the necessary protocols and formats for account data import and export
• Developing open-source easy-to-use tools that allows people to export, import and migrate their account between XMPP services
• Building this functionality into Snikket

The standards will be submitted through the usual XMPP standards process and the implementations will be open-source.

XMPP already has some existing standards that overlap with this project, in particular XEP-0227 and XEP-0283. Both specifications are outdated and incomplete (XEP-0227 doesn’t support many modern features, and assumes your password will be exported in plain text!). We will update and/or complement these documents as needed.

The final stage of work will be to integrate the migration mechanism into Snikket. This will allow people to move their accounts between Snikket servers, including to or from our hosted service as well as other XMPP servers.

Our not-for-profit organization is committed to sustaining the Snikket project through ethical means and without the influence of private investment. We are very grateful for initiatives such as NGI, allowing projects like ours to fulfil our ambitious goals with open and transparent funding. Every project funded by them is helping to rebalance the internet.

We look forward to sharing further updates on this project in the coming months, so stay tuned! You can follow us on Mastodon and Twitter, or subscribe to this blog’s RSS feed.

This week we are excited to announce the release of Harrier 3.1 and Cobalt 1.1.

These releases are an important step for our Draft, Review & Release Solution, a capability of particular interest within Military Deployments.

Draft and Release is a process of handling formal military communication, it is vital for scenarios where formal responsibility must be taken for messages sent. For example, Military commands sent as messages needing to be approved/released by an appropriate senior officer. More information on this can be found in our recently updated whitepaper.

This latest release of Harrier provides a new, simple and intuitive UI for drafters, reviewers, and releasers, making each task straightforward. Also included is a visual workflow, allowing easy tracking of messages.

There will be situations where it makes sense to send directly and to avoid any workflow. Cobalt allows simple control of users who can send directly for selected messages based on SIC and Priority.

Cobalt provides a range of capabilities to support Formal Military Message Handling Systems (MMHS), with capabilities oriented towards the support of systems using Isode’s Harrier, M-Box, and M-Switch products.

Downloads and accompanying release notes can be found in the evaluator and customer sections of the website.

April brought an all new message styling parser, making Gajim fully compliant with XEP-0393. This post will also give you a sneak peek on some features we’ve been developing for the past months: the new Chat view and Contact Info window.

Changes in Gajim

As promised last month, this post will cover some of the new Chat view features we’re currently developing. April brought a lot of code refactoring, making Gajim ready for all of the new features which are planned. But let’s have a look at the new Chat view (work in progress):

Each message type (e.g. info message, chat message, subject) features its own Row. This enables Gajim to apply distinct styling and elements to the various message types. Info messages for example are displayed with lower contrast, in order to move the focus on actual chat messages. Group chat Subject messages are placed in a separate box to display them prominently. Each chat Row offers a button for further actions, such as quoting or copying message content. The new Chat view also enables you to scroll back infinitely ⬆️.

Looking at the screenshot, you may notice further styling details for chat messages: Quotes are now highlighted and indented. Nested quotes are possible as well. Code blocks surrounded by backticks ``` will now be displayed inside a code widget, including code language detection, syntax highlighting, and a code block copy button. The whole message styling parser has been rewritten from scratch, making Gajim fully compliant with XEP-0393 (Message Styling).

As mentioned in last month’s news, the Contact Info window also received an update. It takes advantage the Info Grid we introduced for the new Profile window. Sharing the code base between these two windows significantly reduces maintenance effort. The new Contact Info window features a settings page, where contact subscription actions are displayed. This page will most likely offer further settings in the future. Contact group management has been moved into a page as well, making the old group management dialog obsolete. All devices of your contact are now neatly displayed on a Devices page. There could be even more pages in the future, e.g. an OMEMO page for fingerprint management.

This is only part of what we’re planning to do for the next release of Gajim. We’ll show more details with the coming blog posts. Stay tuned!

What else happened

• #10541: Fixed using custom port in connection settings
• #10540: GSSAPI dependencies have been added to the Windows build
• #10342: UnicodeDecodeError related to avatars has been fixed (this error prevented translations on Windows)

Plugin updates

Gajim’s PGP (Legacy) plugin received an update which fixes sending files. Both OMEMO and URL Image Preview are now able to correctly display files from URLs containing ? characters. Also, a nasty file transfer issue which occurred when trying to download a file which had been deleted (HTTP 404) has been fixed (#9999). Furthermore, Gajim’s Acronyms Expander now features improved word detection, enabling you to substitute short codes with emojis, for example : robot : with 🤖️ .

Changes in python-nbxmpp

No changes in python-nbxmpp this month.

As always, feel free to join gajim@conference.gajim.org to discuss with us.

The Ignite Realtime community is happy to announce the release of Spark 3.0.0 Beta version.

We decided to increase major version to 3.x to coincide with a complete UI refresh of Spark which was contributed by Amos. We are very much grateful for his incredible work. Along that Pade Meetings plugin was added by Dele. And a few other fixes and improvements by others. We wanted to have a few more items for this major version, like latest Smack library, Carbons support, JCEF, etc. But there are not enough time and contributors to get everything done. Hopefully will be added later.

As this is a major visual change and there are a few other changes under the hood, we decided to first do a Beta release and let it cook for a while. Feel free to test it and report any findings in the forums.

Pade Meetings (formerly SparkMeet) plugin is included in this release. You can find it in a chat window, a button with P letter. This plugin works with Openfire Meetings and enables audio and video chat. It was modified by Dele Olajide to use Electron technology. First time a user logs in using this version Spark will download required libraries into user’s profile (it is around 150 MB on Windows, so can take a minute to download).

Full list of changes can be found in the changelog.

We encourage users and developers to get involved with Spark project by providing feedback in the forums or submitting pull requests on our GitHub page.

You can download Spark Beta from the Downloads page. Below are the sha1 checksums:

796264c0bc1df74f6e36926e30c14b3035c86cbb  spark_3_0_0-beta.deb
4c8322d315f99c70bd7704e469a1ffe95aa92636  spark_3_0_0-beta.dmg
22972b4cbab947efd5eee578b43860b711fdab72  spark_3_0_0-beta.exe
7ce6e743be5a4fab867c4aca6ac6d3f1c8edd1e3  spark-3.0.0-beta.rpm
b695386e47c4eefffaeb2c4d0a3eed884a4a021f  spark_3_0_0-beta.tar.gz
aeacdddb9b1640aedc56a3ff0fd466ad5303de73  spark_3_0_0-beta-with-jre.dmg
a51fbf9e7b92206b037bc6eaa10454942a7ef26b  spark_3_0_0-beta-with-jre.exe

For other release announcements and news follow us on Twitter

3 posts - 2 participants

Read full topic

Do you want to install ejabberd on your Windows 10 machine? Do you miss the binary installers for Windows? Don’t worry, you can install ejabberd on Windows 10 using Docker Desktop, and this tutorial guides you through the process.

This tutorial requires Windows 10 or newer. For older systems like Windows 7 or 8, follow the tutorial on how to install ejabberd on Windows 7 using Docker Toolbox.

For some time now we have been phasing out the traditional installation wizards, customary to the end users on macOS and Windows, in favour of the more streamlined command line approach, well known on Linux desktops and servers.

First, we have phased out the macOS binary installer in favour of a quick brew install ejabberd command. Then, since ejabberd 20.07, we have phased out the Windows installer in favour of a container solution. However, setting ejabberd in Docker requires setting volumes, ports and some customizations, so we’ve written a batch script that performs all those tasks for you.

This tutorial explains how to get any ejabberd version installed on Microsoft Windows 10 using Docker Desktop and ejabberd-docker-install.bat script.

Docker Desktop is only available for Windows 10. If you use Windows 7 or 8, you can use Docker Toolbox, which is old and obsolete, but it still seems to work correctly, so give it a try. We published a tutorial explaining how to install ejabberd on Windows 7 using Docker Toolbox.

1. Install Docker Desktop

First of all, download and install Docker Desktop for Windows. The process is pretty straightforward, and it will ask you to restart your machine.

The installation wizard may ask you to install Microsoft’s WSL2 and restart the Docker Desktop app.

2. Download ejabberd-docker-install.bat

Download ejabberd-docker-install.bat to your machine.

3. Edit the install options

Edit this batch file with your favourite text editor and set, at the very least, the PASSWORD option you want for your new ejabberd administrator account.

Additionally, you can set some other options: INSTALL_DIR_WINDOWS10, HOST, USER, VERSION, and PORTS.

4. Run the script

When you run the script, it will open a console window to inform you about the process: download the ejabberd image, create the container, register the admin account and prepare the configuration file…

If installation completes correctly, you can close that window and proceed to next step.

If there was any error, solve it and run the script again. You can delete the script and download it again, or delete the ejabberd container, or delete the ejabberd installed directory… and run the script again.

5. Start ejabberd

Now you can finally go to Docker Desktop, where you can see the new ejabberd container, and click the “Start” icon:

Wait a few seconds till ejabberd is started in that container and accepting connections:

Next steps

At this point, you have ejabberd installed and running on your machine, and you may be asking yourself how to administrate it. Here are some remarks:

ejabberd.yml, database and logs

The configuration files, Mnesia internal database spool and logs directories are available for you to edit and inspect in Windows, in the path that you specified in the INSTALL_DIR_WINDOWS10 option.

There is also an ejabberd-modules directory, where you can later put additional modules from ejabberd-contrib, or any other place.

Whenever you update to a newer ejabberd, it is a good practice to backup the conf and database directories.

ejabberd WebAdmin

The “Open in browser” icon will open a browser with the ejabberd webadmin page.

Alternatively, you can open it yourself by going to http://localhost:5180 (swap localhost for the value of the HOST variable, if you changed it in the installation script).

You will be welcomed by a browser authentication prompt, where you should type in the login details defined in the installation script: USER@HOST and PASSWORD. You will then see the usual ejabberd webadmin console, where you can easily manage your server instance.

CLI with ejabberdctl

The next icon opens a console in the ejabberd container where you can use ejabberdctl, and that means you can use any ejabberd Administration API.

ejabberd-contrib

In addition to the modules already included in ejabberd releases, there are several more published in ejabberd-contrib, and many other on the internet, and you can even write your own modules.

To start with all this, open the CLI as explained previously, and execute:

bin/ejabberdctl modules_update_specs

For the next steps, check this ejabberd-contrib documentation.

Update from old binary installer

If you already have ejabberd installed using a binary installer downloaded from ProcessOne website:

1. Stop ejabberd using the “Stop ejabberd” desktop shortcut as usual
2. It is always a good practice to backup the conf and database directories
3. Uninstall ejabberd
4. Follow the steps described in this tutorial
5. Check that ejabberd runs perfectly with the basic configuration and empty database

Now it’s time to get back your configuration and database:

1. Stop ejabberd in the Docker Desktop
2. Copy your old conf and database directories to the new location
3. Start ejabberd and check if it runs correctly

Update to a new ejabberd version

When a new ejabberd version is released, go to ejabberd Docker Hub, and check if the new version is available in Tags.

How to install it?

1. Delete your old ejabberd container
2. Edit the VERSION option in ejabberd-docker-install.bat
3. Run the script

It will download the new image and create a new container.

If something goes terribly wrong

As mentioned previously, if something goes terribly wrong, don’t worry! You can delete the script, or the installed directory, or the ejabberd container, and start from scratch.

Docker Desktop in macOS and Linux

Docker Desktop is also available for the macOS and Linux systems. While the above installation script is designed for Windows, it could be modified for these other platforms as well. This means you now have several methods of installing and running ejabberd on any given operating system: using a package manager (like apt on Debian or brew on macOS), using a Docker container, with a binary installer (on Linux) or building from source.

Questions, problems, suggestions

The batch script to use Docker and this tutorial may have problems or incorrections. So, please add a comment here, or join the ejabberd chatroom, or send an email to the ejabberd mailing list or fill a bug/suggestion in the ejabberd tracker or docker-ejabberd trackers.

Photo by Frank Mckenna on Unsplash

The post Install ejabberd on Windows 10 using Docker Desktop first appeared on ProcessOne.

This release brings back translations for Windows users. Gajim 1.3.2 also includes some small fixes and improvements. Thanks everyone for reporting issues!

What’s New

For Gajim 1.3.0 and 1.3.1 we had to disable translations on Windows. This was due to a bug in a package Gajim relies on. After some detective work, this bug has finally been resolved. This enables us to ship Gajim with translations again!

More Changes

New

• Added account switch description (On/Off) for better accessability

Changes

• MessageInput: Removed custom placeholder (‘Type a message…')
• MessageInput: Added focus borders for better accessability

Fixes

• #10010: A domain name conversion issue
• #10342 UnicodeDecodeError related to avatars (this error prevented translations on Windows)
• #10428: Fix for handling a missing avatar_sha

Known Issues

• Zeroconf (serverless messaging) has not been re-implemented yet
• Client certificate setup is not possible yet

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab.

Our Vaxbot (vaccine.monal.im) has continued to grow. We just hit 8 million messages sent and send around 800,000 messages a day. XMPP and Vaxbot have been on TV news in Las Vegas and South Carolina, the radio in Washington as well newspapers all over the country. We mention XMPP and try to explain it as much as we can, some reporters do a better job than others.

Over at the yax.im blog , Georg Lukas goes into some detail about the technical challenges of handling the message volume we have generated. Thanks to the prosody team for helping him made adjustments so handle our message blasts without causing downtime. Thousands of Americans have used XMPP for the first time and this number will continue to grow. April 19th was a big day because the vaccine will be available to every adult in the country now. I expect to see additional spikes in users. Thankfully, we also have a chat-bot interface now made by Friedrich and Thilo from the Monal developer team and are retiring the old web interface for registration. People can send stop to unsubscribe and just click an XMPP link to subscribe to the bot. This has helped with the scale.

Still, there are a few thousand users at any given moment with people unsubscribing as they have their appointments (and hopefully keeping the apps installed). This is the opposite of a social network where are trying to keep a user base for the bot. In fact I would prefer people unsubscribe when they have their shot. Realistically in a few weeks the need for this bot in the US will be gone. Hopefully we can replicate this kind of service internationally.

Info: VaxBot is a free service that helps you find vaccine appointments in your state or country if available. We send notifications to your device so you never have to hit refresh. If you have got vaccinated you can opt-out. Of course you are welcome to continue the XMPP-based messaging technology we provide under a free license for everyone. You can follow the usual messaging app Monal IM via Twitter and Fosstodon. Find the open-source code on GitHub.

Everyone stay safe!

Over the last two years, Isode has been working alongside other HF experts to update STANAG 5066 from edition 3 to 4, motivated by the need to keep this vital standard current with the latest messaging developments.

One particular area of interest for Isode is enabling TCP applications to perform efficiently over HF links and our CEO, Steve Kille, gave a presentation in this area at the most recent HFIA meeting back in March. You can find a PDF of the presentation, ‘Web Browsing over HF’, here.

In an ideal world all mission-critical applications would take advantage of specific optimized protocols for HF but, as it’s impractical to do this for every service, having mechanisms to support generic services that run over IP in high-speed networks is necessary.

To provide IP services over HF in a reasonably efficient manner, a central challenge is to provide a mechanism to support TCP-based applications efficiently. This can be done with a TCP PEP (Performance Enhancing Proxy), such as our recently announced Icon-PEP product.  Icon-PEP product enables deployment of IP Applications over an HF network using STANAG 5066 link layer as the interface to that network. More information can be found on the Icon-PEP product page.

The Ignite Realtime Community is pleased to announce the release of Openfire version 4.6.3. This release contains a number of bug fixes and denotes our desire to provide stable 4.6.x series releases while development work continues on a 4.7.0 release.

You can find download artifacts available having the following sha1sum values:

df31aa19f035454cbddb91ac461e17ab5afe9d0e  openfire-4.6.3-1.i686.rpm
5c7d95f508426f9ffbe4140c7f217bb5308456fe  openfire-4.6.3-1.noarch.rpm
72a0f054cbb22ca89b3776889ec6f23ba16a2744  openfire-4.6.3-1.x86_64.rpm
28ceb205504e7f58cea30a21e8d8fb3ff197f18d  openfire_4.6.3_all.deb
130b1182384b4ebf08826b4efd84ab83d968a9bd  openfire_4_6_3_bundledJRE.exe
2e25f3924eadd0e1992ccefb2ca2b955801e1d2c  openfire_4_6_3_bundledJRE_x64.exe
c5c2035dec1a9aced5d4979b83da64686e2575a1  openfire_4_6_3.dmg
57e2a211dcb8d93c7362282f469bdc7ee7e4d06d  openfire_4_6_3.exe
ab4f6a0ab27dd642214099ea57a6ac4e2eb6d75f  openfire_4_6_3.tar.gz
21785833b7b1ec99f9174fdb625529dacd4f832c  openfire_4_6_3_x64.exe
de5bff5f8b6963d8c8e2d25120922a3395dd0df7  openfire_4_6_3.zip
30e97fa43ba34dd3369c7664c40dd087db0e6879  openfire_src_4_6_3.tar.gz
6acb86fee6f64b940089eba571a3136caa08df9d  openfire_src_4_6_3.zip

Please report any issues you have with this release in our Community Forums.

We are always desperate for folks interested in pitching in with development, testing, and code reviews. Please consider dropping by our webchat forum if you are interested in helping.

Thanks again for your interest in Openfire!

For other release announcements and news follow us on Twitter

2 posts - 2 participants

Read full topic

Bulletproof systems, scalable distributed SQL databases. 

The new partnership between Erlang Solutions and Cockroach Labs allows organizations to build fault-tolerant and scalable technology on an open source distributed SQL database. Erlang Solutions is the world’s leading provider of Erlang and Elixir solutions and Cockroach Labs is the creator of CockroachDB, the most highly evolved cloud-native, distributed SQL database on the planet. Working together gives our clients access to end-to-end scalable solutions, built for resilience, that are able to handle extreme spikes in concurrent users, without any weak links in the tech stack. 

Erlang Solutions is dedicated to making fault-tolerance and scalability commonplace, we work with the world’s most ambitious companies to ensure their systems are elegantly and reliably able to handle the demands of their users.  CockroachDB guarantees built-in data locality for lower latency and faster performance, and a data infrastructure that is always on and always consistent. Using CockroachDB in our systems will allow us to easily ensure that databasing components meets the demands and standards of the solutions we build. 

“The Cockroach Labs team is excited to formally announce its partnership with Erlang Solutions. Both organizations align strongly, not only within the verticals we service, but in our commitment to excellence and delivering world class solutions to our customers. We look forward to growing a strong global customer base with Erlang in 2021 and beyond.” – Jen Murphy, Global Head of Channels & Alliances

CockroachDB is the latest technology partner to join forces with Erlang Solutions enabling our expert consultants to support, offer and work with the widest range of up-to-date solutions and ensure we are able to deliver our partners the best tool for the job every time.

“We are delighted to be working with CockroachDB to provide industry-leading distributed SQL databases to our customers. Our customers come to us because of our deep expertise in building highly scalable, distributed systems and the addition of CockroachDB to our portfolio further enhances that capability.” – Francesco Cesarini, CEO of Erlang Solutions

Webinar – Scalable, bulletproof distributed SQL databases made easy with CockroachDB

About Cockroach Labs

Cockroach Labs is the company behind CockroachDB, the cloud-native, distributed SQL database that provides next-level consistency, ultra-resilience, data locality, and massive scale to modern cloud applications. Companies like Comcast, Lush, and Bose are building their cloud data architectures on CockroachDB. Cockroach Labs was founded by a team of engineers dedicated to building cutting edge systems infrastructure, and has investments from Benchmark, G/V, Index Ventures, and Redpoint. For more information, visit https://www.cockroachlabs.com.

The post Erlang Solutions partners with Cockroach Labs appeared first on Erlang Solutions.

Mac and iOS betas are now up.

NOTE
THIS BETA WILL DELETE ALL EXISTING MUC MESSAGES AND MUC BUDDIES.
MUC SUPPORT IS CURRENTLY IN A ALPHA STATE.

Ready

• basic group message support (without (pleasing) UI)
• Message quote action
• Fixed appex / main app race conditions
• Displaying group messages in activeChatsViewController
• Displaying ToFU
• Using transactions (read / write)
• Added image quality slider
• Connected download slider
• Buddies can be muted per account

Todo

• Show Emoji in bigger font
• Better unread msgs counter handling
• Delete message_history backup table. Let’s see how many crashes we see
• MUC UI
• Display message quotes in a fancy style
• Adding upload preview to the chatViewController
• MUC OMEMO
• voice messages may not work as expected

I have to first start by admitting that my judgment is probably compromised by my desire to have a paycheck, which is part of why I’m pushing this so hard. I’m likely about to lose my 9 to 5 and to prepare for that I’m applying for part-time work in retail hoping I can stretch my savings long enough to actually drum up some freelance work or find some other way not to have to work for large tech companies that pay well but treat their employees like dirt. I’ll be trying to take on freelance work either way, but I’d prefer to do it cooperatively with others.

That being said, though it’s consuming me a bit right now, I’m not just looking to make a paycheck out of this. I’d like to create the kind of place where anyone can feel comfortable applying and not feel like they have to be on their toes to pass a culture fit interview conducted exclusively by 20-or-30-something white men with beards. I also like the idea of a business that doesn’t try to operate on the thinnest of margins and focus exclusively on growth at all costs.

It’s important to me that the whole co-op be comfortable with (and know about) any clients we take. I’m not against discussing most things, and am open to being convinced otherwise, but I would likely vote against Defense/Police/ICE work, Right wing political campaigns, adtech, etc.

That being said, I would also not vote against someone joining the co-op who disagrees with me on any of those points.

A quick aside on the word “free speech” that Redoak mentions in his writeup: Organizations that aim to promote “free speech” but really just mean “we don’t moderate and we’re trying to co-opt the term ‘free speech’ and make it meaningless” I would vote against, but organizations that actually understand what free speech means (ACLU, EFF, FFRF, etc.) I would like to support.

Goals for the Co-op

One thing I’ve thought about doing for a while is teaching. It’s always been something I enjoy, but never something I’ve had the opportunity to do much of. I’d like to eventually be able to expand the co-op to include training, and I’d particularly like us to teach both introductory courses (probably at a steep discount for individuals wanting to learn about software) and more team-oriented corporate courses (the actual money maker, and hopefully we can improve the state of software for the users).

We will likely make use of a great deal of open source, and if we’re ever successful it would be important to me that we give back to those who made our success possible. The cooperative principals should be applied to software as well, so if we use an open source library and make money from doing so I would argue we should take some portion of that (in capital or labor) and set it aside to donate upstream if we are able to do so.

Target Areas

We’d likely have to take work where we can get it of course, but here are some areas I’d personally love to work in one day:

• Other co-ops
• Theaters (not a lot of money, but they often need tech and no one is developing it; maybe this would be more from a product development side)
• Solar/clean power sector
• Accessibility improvements in any sector
• Local government or administrative agencies (which are an under appreciated national treasure)
• Local improvements where our members live
• Open Source (I have at least one lead on a small open-source-first company looking for contractors that I will follow up on and hopefully bring in as a client for us to consider)
• Libraries (a friend does this sort of work out in Portland; Library software is terrible)

Personal Goals

I am not good at putting myself out there and talking to clients. Selfishly, this is another reason I’d prefer to look for freelance work with other people who may be able to do this better than I can. However, it’s also something I’d like to learn.

In general, I don’t feel like I’ve learned much at all from my last few jobs, so having a team around me that has a lot of different skills (and hopefully is okay sharing them) is something that appeals to me a lot in general, and I hope I’d have something to contribute to the groups knowledge in return.

My Skills

I am a backend developer who has worked primarily in Go. I have been working in this space since approximately 2013. I have also worked extensively in Rust, Python, and (to a lesser extent) Clojure among other languages.

I also have experience in realtime communications and have served on the XMPP Standards Foundation (XSF) council (the technical governing body) as well as an editor for the XEP series of documents.

To a lesser extent I have been minimally involved at the IETF with the PRECIS (internationalization), KITTEN (authorization), and TLS (TLS) working groups.

On a scale of 1–5 where 5 is “expert” and 1 is “don’t make me do this, the client will regret it” and an asterisk is “needs refreshing to get back to this number”:

• Go (5)
• XMPP (5)
• Rust (4)
• Terraform (4)
• Linux/FreeBSD administration (4)
• Hugo static site templates (3)
• HTML/CSS (3)
• Technical Writing (3)
• PostgreSQL (3)
• Python (3*)
• Clojure (3*)
• Android (2*)
• SmartOS (3*)
• Web Design (2)

After much research and some helpful input from double bassist Mark Stefaniw, the unofficial artistic advisor for my "Bach on Bass" project, I've chosen to buy a Stradi bass made by Marek Dąbek of Juliszew, Poland. Not only does Marek make absolutely gorgeous instruments, but he was excited to work with me on a design that met all my criteria: a four-string fretless bass with tapewound strings tuned in fifths, a very long fingerboard with a deep cutaway so that I can play intricate passages high up on the neck, a combination of piezo and magnetic pickups (the latter is important to enable experimentation with an eBow on certain pieces), and a chocolately tone that balances the best of electric and upright bass sounds. A long email thread with Marek led to a bass that is all oak, a wood we both love: roasted European oak for the body (chambered to enhance its acoustic properties), a hybrid through-body neck also in roasted oak, and both the fingerboard and top in 2000-year-old bog oak. Since Marek likes to name his basses, we're calling this one the "Mocha 4". The only bad part is that Marek is a true artisan who makes only 20 instruments a year and has a large backlog of orders, so I won't get my hands on the Mocha until early next year. But it's going to be worth the wait!...

A few days ago, VaxBot, a new XMPP-based vaccination appointment notification service was launched in the USA. The service is recommending Monal and yaxim as client applications, and both apps by default register accounts on yax.im.

This has brought us hundreds of new users (per day) and a significant amount of new traffic from the notifications, sometimes up to 200 messages per second. The additional traffic load caused some short service interruptions in the last days, and we are working together with the VaxBot team on implementing mitigations.

The VaxBot service started in mid-March in Massachusetts, and is slowly expanding to more and more states, hoping to also spread over the ocean. It was even featured on TV (archive links for EU citizens: FOX5, WBTV)!

This has lead to a significant uptick in yax.im account registrations, as can be seen in this graph:

Once a user registers with VaxBot, it will automatically send them appointment notifications for their region as soon as they become available.

This means that for each potential appointment, a message will be sent to each registered user in the region. When a large chain opens up additional capacities, thousands of messages will be generated and sent out in a burst.

As those are chat messages, they need to be stored in the respective user’s account, delivered to online devices, and forwarded to the respective push service to wake up a mobile device.

Due to how the server is processing messages, a large message flood from one connection can “capture” the processor for multiple seconds or even longer, leading to the starvation of other connections, causing delivery delays and even disconnects.

As a preliminary measure, we have implemented a rate limiting mechanism to reduce the impact of message bursts from VaxBot, and we are working on optimizing the number of messages generated by the bot and on increasing the server performance to be able to further scale up.

A long-term solution based on XEP-0060: Publish-Subscribe would be interesting and probably much more efficient for the infrastructure, but that would require significant changes to all clients, and vaccination can not wait.

DSEI is the premier showcase for military technology of all types. Held every other year, DSEI attracts one the largest international audiences, with over 75,000 visitors from 114 countries at DSEI 2019.

Isode will be displaying a number of unique capabilities at DSEI 2021, which you can see on our stand on the UK Pavilion, including:

Military Email

Isode’s end-to-end solution fronted by Harrier, our web based military messaging client, and including message servers and gateways covering all of the major military messaging standards.

Isode Harrier Web-based Email Client for Military Messaging supports the draft and release process to support formal release and approval of messages by an appropriate officer.

Military Instant Messaging

Instant messaging, using the XMPP standard, is an increasingly important component of military communications systems. Isode clients, servers and gateways allow XMPP traffic over standard and constrained (SatCom/HF) links a s well as between XMPP and legacy instant messaging systems such as IRC, all of which can be controlled using Isode’s extensive security labelling infrastructure.

At DSEI 2021 we will be giving the first public demonstration of the web version of our Swift XMPP Client.

You can find more information on Isode’s products set for Military Messaging and Military Instant Messaging by following the links.

Isode Military Messaging and Military Instant Messaging products have been successfully deployed with the land, air and naval forces of over 30 countries.