Dino is a secure and open-source messaging application. It uses the XMPP (Jabber) protocol for decentralized communication. We aim to provide an intuitive, clean and modern user interface.
The 0.2 release adds message correction, improves the file upload functionality and provides more information about message encryption. Besides other smaller changes it also fixes a number of bugs.
It is now possible to correct the last message you sent. You can access the function by hovering the message that you want to correct and then click the edit button that appears. If you’re a fan of shortcuts, you can also press the UP key. Last message correction has been the most frequently requested feature addition so far. We are happy about how it turned out and hope you are, too!
You can now send files via drag and drop! Furthermore, you can now send Images by pasting them from your clipboard. As before, there is also still the option to press the “Send a File”-button.
Especially with those new ways of sending a file it is important to know that you are sending the right file to the right person. That’s why Dino now presents a confirmation dialog with a file preview and some file details.
It has already been possible to accept, verify or reject OMEMO keys. Now you can see the relevant information alongside each message: A small lock or seal symbol above a message indicates whether the message was encrypted by an accepted or a verified device, respectively. A red, open lock warns you in case your contact sends unencrypted messages in an encrypted conversation.
Dino now displays the number of unread messages in the conversation list. The color of the circle tells you whether the new messages triggered a notification (e.g. direct messages, mentions in channels).
Furthermore, Dino lets you know in case your message has not been sent yet by displaying “pending…” alongside the message.
In moderated channels, Dino will inform you if you don’t have the permission to write messages and offer the possibility to request that permission from a moderator.
Coral reefs are diverse and important ecosystems. Climate change and local human influences endanger coral reefs around the world. We named this Dino release “Mexican Caribbean Coral Reefs” to help spread the word about what needs to be done to preserve these unique ecosystems.
While coral reefs only occupy 0.1% of the ocean area, they are home to 25% of all marine species. Those reefs are made up of the calcium carbonate skeletons of corals. Corals grow very slowly and thus reefs require thousands of years to form. Many tropical corals live in symbiosis with tiny algae, which provide the corals with nutrients in exchange for shelter.
Climate change harms corals in two ways: First, it raises the ocean temperatures. Corals lose their algae in high water temperatures, which is called “bleaching”. Without the algae the corals starve. Secondly, the ocean absorbs parts of the increasing carbon dioxide amounts from the atmosphere. In water, CO₂ reacts to carbonic acid, which dissolves coral skeletons.
Many coral reefs are located in the shallow water near coasts and are thus highly affected by local human activities: Sediments and nutrients are washed into the ocean and deprive the corals of light; Overfishing can negatively affect the whole ecosystem; Destructive fishing using poisons or explosives harms the corals.
For example, the coral cover in the Mexican Caribbean Coral Reefs decreased by 60% between 1980 and 2016. This was caused by mass bleaching events due to increased water temperature, hurricane impacts, and an increased amount of sediment due to deforestation .
Various programs aim to protect individual coral reefs from local dangers. However, the ecosystem coral reef can only be preserved by also eliminating the global threat: Climate change. According to multiple studies, coral reefs only have a chance of survival if the global temperature increase is limited to 1.5°C [2, 3]. Your actions have an impact.
New versions of XMPP clients for Apple’s mobile and desktop platforms have been released. The biggest change is introduction of XEP-0215: External Service Discovery which helps with establishing audio and video calls.
The stable release of BeagleIM 4.1 contains a lot of changes and stability improvements.
altwhen sharing image file)
The stable release of SiskinIM 6.1 contains changes and stability improvements.
You can discuss all-things-Tigase (including our client apps) on our groupchat: email@example.com
We recently helped deploy a new XMPP service for the IETF. But before we go any further, some of you are probably asking - “what is the IETF?!” If you’ve been around the XMPP community for a while, or if you’ve been at all involved in internet development discussions, you’ll already have an idea of what the IETF is. But that leaves many people don’t know, so here goes…
The Internet Engineering Task Force is the organisation that has been behind many of the most widespread internet technologies in the past 30+ years. Even if you aren’t familiar with the IETF, there’s a chance you may have stumbled upon one of the documents they publish, known as RFCs (Request for Comments). Contained in the 8000+ RFCs that are currently published is a mass of knowledge about the design of the internet - past, present and future.
As well as XMPP’s own RFCs (RFC 6120 and RFC 6121), there are RFCs that describe the workings of IPv4 (RFC 791) and IPv6 (RFC 8200), email, including SMTP (RFC 5321 and RFC 5322) and IMAP (RFC 3501). Many other internet technologies are also standardized by the IETF - including for example, DNS, HTTP, TLS, LDAP, SSH and SIP.
Unlike many standards organizations, the IETF publishes its standards openly for the benefit of everyone developing internet-based technologies. Likewise, participation in the development work of the IETF is relatively straightforward and happens via mailing lists, online sessions and (usually) in-person meetings.
XMPP was officially published as an RFC (3920) in 2004 as a result of a lot of hard work performed by the community, and Peter Saint-Andre working as the document’s author. This document also marks “XMPP” taking over as the formal name of the protocol, rather than “Jabber” as it was originally known.
XMPP had a dedicated working group at the IETF, which went on to publish many other documents, including updates to the original RFCs.
As well as standardizing the protocol itself, the IETF have long been users of
XMPP to provide options for remote participation at meetings (along with e.g.
live audio streams). Their service at
jabber.ietf.org hosts chats for the
various working groups,
and provides a place for collaboration and discussions between meetings as well.
That said, the deployment is starting to show its age, and has not evolved much in its feature set since it was originally launched. Recently there has been some focus on the problems that people face when trying to access it for the first time.
Notably, people reported issues with installing software (e.g. on restricted company laptops), problems with firewalls, and difficulties finding and registering accounts on public XMPP servers.
In search of a more user-friendly solution, the IETF announced a temporary trial of Matrix and Zulip as potential alternatives, so they could gain operational experience and feedback from users.
Comparison between these alternatives and the existing XMPP deployment had a number
of problems. For example, while
jabber.ietf.org (by intention) didn’t allow account
registration, the alternative services did. The other services also prominently feature
(or even require) access via the web, yet there was no similar web access for
XMPP chats - an option which would solve the vast majority of problems that people face with
the current setup.
Building on recent work we’ve done to improve and simplify web-based account sign-up in Prosody, we put together a demo server to show exactly how a user-friendly XMPP setup may be provided. The sign-up processes uses the new client-agnostic mod_invites_page, and the web client is served using mod_conversejs. The IETF infrastructure team were able to replicate the setup and it is now deployed at xmpp-trial1.ietf.org!
The trial of all the new services will be discontinued in January 2021, and the findings will be assessed before a decision is made about the future of real-time communication at the IETF.
When talking about servers, this question is asked over and over again, and, MongooseIM is no exception. How does it scale? It scales well, this we know. We’ve done a lot of load tests in various environments, we’ve set up multiple production clusters, some of them handling a substantial load. But, more specifically, how does it scale?
It is a difficult question and requires a careful insight (never say that in a TV interview, it is the worst answer you can possibly give). But, it really is. It depends on so many factors – underlying hardware, usage pattern, enabled extensions, database backend, integrations… We’d love to have a definite answer to the question, but is that even possible?
This is what my car spec says is its top speed is. Does that mean I can drive it that fast? First of all, no because I’m not going to try. Even if I did, I certainly won’t make it, for a variety of reasons – the car is not brand new, driving conditions are never perfect, I have regular tyres which are designed for security and not for speeding, etc. What the manufacturer is really saying is (a) you won’t go faster than that no matter what you do, and (b) something like 180km/h is absolutely fine (if legal).
So let’s follow this approach and find out what the “top speed” of MongooseIM is. Along the way, we’ll also examine how it behaves when we expand the hardware, both horizontally and vertically, what is limiting its growth, and some other interesting aspects.
We ran our tests on AWS - it is the most commonly used general-purpose cloud environment. Results from there can serve as a benchmark. A set of ansible scripts provisioned an EC2 instance, installed and configured MongooseIM. Then we launched the “client” EC2 instances one by one, each establishing a number of XMPP connections pretending to be real clients. We proceeded with it until either new connections started failing or the end to end time to delivery shot up, then we terminated the whole test.
The MongooseIM server was “plain vanilla” - the goal was to test just the main functionalities, like handling connections and routing messages. If a cluster of servers were used, clients would connect randomly to any of the nodes available - there was no load balancer to get in the way. Client behaviour was also rudimentary - a single “client” would establish a stream, authenticate and then keep the connections open, sending one short message every minute and receiving whatever came in. Messages contained timestamps, so that we could track end-to-end time-to-delivery.
After experimenting with a number of instance types, we found out that the c5 line is a perfect balance. With our assumed usage pattern, this hardware profile provides just the right combination of memory and CPU power. Memory-optimised instances of a similar size offers a similar performance, while being much more expensive - there is not much to gain by adding more memory. Also, results from running memory-optimised instances were unstable, since the CPU usage of MongooseIM had many spikes which may break the tests at any time. Here are some examples:
Our imaginary average user sends one message per minute - with 137k connections on c5.large instance, this means that MongooseIM is routing about 2.3k messages per second. What if our users become more active, or less active - how does it change the maximum load we can handle?
Less messages means the CPU has less work to do, but memory pressure stays the same. The expectation, therefore, is, that when the traffic is low, the maximum number of connections should not depend on the traffic. This is because, in that scenario, the memory is the limiting factor. On the other hand, if the load increases, at some point, it should overload the CPU and the maximum number of connections should start to fall.
Our tests confirmed this, and also proved that the default usage pattern of one message per minute is just about the breaking point. Below it the limit stays the same. Go slightly above it and the limit begins to fall.
Now that we know that c5 line provides a perfect balance, how will using a more powerful variant help? Again, is it linear? Does doubling the digit before letter “x” actually double the load we can handle? Is there a limit to it?
This was tricky, because there are many OS-level limits and Erlang VM settings which can stop your node from accepting more connections. For details on how we configured our servers, consult MongooseIM documentation available online.
We ran our test on larger instance types, up to c5.9xlarge. At that level, MongooseIM was able to handle almost 2.5 million connections, passing 45 thousand messages per second. And no issues were found, so there doesn’t seem to be a real hard limit. However, since this was already far more than we were aiming for, and running these tests incurs a considerable expense, in terms of both time and money, we chose to stop here. This is not the end, though, chances are that some day we will try to push it even further.
How does MongooseIM scale horizontally? Is it linear, and if so, how many users each new node can handle? Can we scale ad infinitum, or is there a limit above which there are diminishing returns or even a failure? We wanted to find out, and it was by far the most time consuming part of the whole research.
We were assembling MongooseIM clusters on c5.large instances and stress-testing them until they failed. We went on and on, and scaling was almost linear, with the slope of the line fluctuating about 51 thousands (meaning each new node increased the cluster’s capability by 51 thousands connections, with intercept being about 80 thousands).
And so it went, until we reached fifteen nodes, at over 1.2 million users and 22 thousand messages per second, no limit was in sight. At this point we decided to jump ahead and try twenty nodes. This proved to be too much. Connections between the nodes were timing out every now and then, causing netsplits and inconsistencies in the Mnesia database, and the cluster was basically not functional.
The reason for this is the way Mnesia and, more generally, Erlang distribution works. Each clustered Erlang node maintains active connections to all the other nodes, so the number of connections grows at an increasing rate. With twenty nodes, there were already 190 connections to maintain and exchange data over.
User sessions in MongooseIM are kept in the Mnesia database, which is replicated to all the nodes to ensure strict consistency at all times. Every new connection then triggers a replication mechanism spanning all the nodes and possibly all the internode connections. With this number of nodes, traffic can become quite substantial, no wonder it becomes unstable.
Since we didn’t discover any limit in the vertical scalability, and horizontal clustering is linear (up to a reasonable number of nodes), then by combining the two, we could expect to be able to handle really large numbers - from what we know so far, ten million is well within reach. Taking costs into account, we decided to stop the load tests at this point. Exploring this path is one of the options for the future.
Last but not least, how much does running a MongooseIM cost, and how do the various clustering strategies work cost-wise? Because horizontal scaling is linear with a fixed part, running a smaller cluster is somewhat more cost-efficient than expanding the number of nodes.
Vertical scaling, in turn, is almost exactly proportional - the AWS price list is designed in such a way that an instance which is twice as expensive can handle almost exactly two times more client connections.
The rule of thumb for economic clusters would then be: make a cluster of four or five nodes, and scale vertically if needed. And here we have to reiterate that actual results, from a customised server with its particular usage pattern may vary widely. Keep in mind also that in real life, it is not only MongooseIM you have to scale. Database backends or other external services, which are normally shared by all the instances, have their own scaling patterns, and pricing.
If the load is hard to handle for a single cluster, you can also go beyond that – there is no rule saying that all users have to use the same data centre. With federation, you can set up multiple data centres, each under their own domain, thus multiplying the possible load your whole system can handle. It’d also give you the extra benefit of bringing your servers closer to your geographically distributed uses. Federation also has its idiosyncrasies, but it is beyond the scope of this article (chances are we will get back to it in one of the future installments).
Firstly, there is now the option to leave a voice message if the person you are calling does not answer or is busy. Simply press the green voicemail button to record a message!
There are also many small fixes and improvements, such as the ability to switch back to the chat view during the call, and using the loudspeaker for dial tone and busy tones when making a video call. Finally, a small number of specific devices produced echo during calls, this is now fixed.
As well as searching for messages across all your conversations, you can now also search within just a specific conversation. Simply go to the conversation you want to search in, and choose ‘Search messages’ from the conversation menu.
A notification has been added when message delivery fails, so you know if your contact did not receive a message, even if you aren’t actively looking at their conversation. A bug was also fixed that meant notifications sometimes wouldn’t be shown in some circumstances.
If you’re a regular trekker, this one will be of interest to you. Although sharing and receiving logs of travels via GPX files was always possible in previous versions, they are now automatically identified and show up with a friendly icon. With a single tap you can easily open them in the app of your choice, such as OSMAnd or Trekarta (both open-source and available on F-Droid!).
Some other changes in this release include making it much quicker to restore your account from a backup file, and a fix for a bug that made it impossible to log in when your password included certain special characters.
As always, the Snikket app requires an invite or account on a Snikket service to get started. If you’re new to Snikket, learn more about the Snikket app to find out how to get started.
We’re pleased to announce that Snikket is now backed by a legal entity, Snikket Community Interest Company, registered in the UK.
A Community Interest Company (CIC) is a form of organisation that lies somewhere between a traditional limited company and a traditional charity. All CICs are “not for profit”, which means rather than focus on generating profits and increasing value for shareholders, they have other goals - serving a “community” in some way.
The exact “community” differs between CICs, but must be declared when the organisation is registered with the CIC regulator. Snikket’s “community interest statement” declares that the CIC is for the benefit of:
People and organisations in need of safe and private digital communication. This includes in particular family groups, clubs, local interest groups and other organisations that may be non-commercial in nature.
and that it will also:
[…] provide support to open and non-commercial projects that have similar objectives.
The the term social enterprise has been coined to cover this kind of organisation, regardless of the legal structure used (the options for which may vary from country to country). Although there is no strict definition of what a social enterprise is, they generally all have in common a goal of maximizing their “social impact” alongside or above generating profits.
And this is where a social enterprise formed as a CIC or similar structure differs from a traditional non-profit or charitable organisation. Although the laws vary between countries, a non-profit typically receives tax benefits in exchange for compliance with strict regulations about how it receives and spends its money. Such an entity is usually restricted from trading goods and services for example, and must rely 100% on donations to achieve its goals.
A CIC does not receive the same tax breaks as a charity, however it is free to trade in many of the same ways that a normal company would. This allows for more creative and sustainable ways to sustain the organisation financially, while the CIC protections ensure it keeps a focus on its social mission.
The legal structure of a CIC (particularly the variant that we chose for Snikket) means that it is not possible for us to sell shares, or raise money through venture capital. We feel that this is a good thing - VC funding introduces a certain pressure to ensure a good financial return on the investment. That expectation of return is precisely what makes VC money so very different to a donation (where there is no expectation of return) or a simple transaction where a service or product is received directly in exchange for the money. We wanted to take this option off the table.
What does all this mean for the project?
Well, having a dedicated legal entity means we were also able to open a bank account, which means we can finally accept donations and more easily fund various things. For example, we are seeking funding (e.g. through grants or donations) to help finish the iOS client (if you know anyone who may be able to help get this funded, get in touch!) And even the simple day-to-day expenses such as server costs are now able to be paid from the project’s bank account rather than my personal one. Obviously I’ll still be covering these costs for a while, but I hope in the long run that Snikket will become self-sustaining. This is the first step on that journey!
As for the future, don’t be surprised if we explore additional ways to raise an income - for example through offering services to Snikket users, such as hosting Snikket servers for people who are less able to run their own, or possibly services to help make running a Snikket at home easier. Contact us if you have an interest in either of these, or if you have ideas for other things we could look into offering.
As a not-for-profit, all income raised goes into Snikket and its objectives, such as funding development of the project and the projects it depends upon, and the ecosystem it is part of.
Interested in learning more about starting a CIC or other form of social enterprise? See these resources:
This October brings better message styling, XMPP link handling for Windows, and first improvements to get Voice/Video calls working again.
XMPP addresses are not just contacts or group chats. They can also contain query components to instruct clients to do things with them. For example
xmpp:firstname.lastname@example.org?join would make the client try to join a group chat, and
xmpp:email@example.com?message;body=Hello would instruct the client to open a chat with
firstname.lastname@example.org and pre-fill the message input with ‘Hello’. For this to work, it needs to be supported by the client, of course. Some queries from XEP-0147 (XMPP URI Scheme Query Components) are already supported by Gajim. This month, we added XMPP-URI query support for Gajim on Windows. While installing, you can now decide if you want Gajim to open XMPP links when clicking on them in your web browser.
This month brings some changes to Gajim’s implementation of XEP-0393 (Message Styling). In consequence of these changes, the
_underline_ style has been removed, and a new
~strikethrough~ style has been added, making Gajim standard compliant and thus compatible with other clients. Note that not all styles defined by this standard are supported yet.
Gajim now features a ‘Mark as Read’ button for notifications. If you receive messages you don’t necessarily need to answer, you can just dismiss them without opening a chat window.
Last but not least, there have been some improvements to Voice/Video calling. Gajim has had support for Voice/Video calls for quite some time, but the code has also been broken for a while now, because it is not getting actively maintained. We took some first steps (friendlier user interface, basic audio/video transmission), but these are highly experimental. Also, this feature is based on older standards, which makes it incompatible with Conversations for the time being (for example missing support for XEP-0320).
gajim --start-chat) has been fixed
A bug has been fixed which prevented Gajim’s URL Image Preview plugin from instantly showing previews for voice messages. Also, many plugins have been adapted to changes in python-nbxmpp.
In an ongoing effort, python-nbxmpp’s XMPP request handling is being converted to Tasks (using Python Generators). This simplifies the flow of many operations and makes code easier to read and understand. A lot of work went into adapting Gajim to these changes while refactoring large parts of the code base.
GSSAPI support in python-nbxmpp has been fixed, which allows Gajim to use various authentication providers for user account credentials.
As always, feel free to join email@example.com to discuss with us.
Have you got the message? Chat is a critical feature for almost every business, in virtually every industry. Now, more than ever, digital communication is relied upon to share information and keep our contacts and users in touch. We’ve created bespoke chat applications for use cases as varied as large scale medical or digital health providers, industry-leading financial service providers and modern dating apps. For business-to-consumer uses, chat is a great way to turn your app or business into a community, keeping users engaged and adding a social element to your applications. On the other hand, in the B2B space, chat applications can be used to increase collaboration and productivity. In fact, external research conducted by one of our clients TeleWare found that instant messaging was the most in demand feature for a financial service app.
In this blog, we’ll look at some of the key considerations for an Instant Messaging service as well as the must-have features of the modern chat application and how MongooseIM 4.0 stacks up to deliver what you need.
One of the first considerations a company needs to make when implementing a chat offering is whether to use an out-of-the-box product-as-a-service or software-as-a-service offering or build your own chat. Below we weigh up the pros and cons of each approach.
The key benefits of an out-the-box purchase solution is that you are able to deploy quickly. The bigger players in this space often offer a comprehensive set of integrations and require little to no development from your team. They also provide users with a familiar user-interface, which means they’re incredibly quick for anyone to learn how to use. All of this means you can be up-and-running quickly with the peace-of-mind that you’re using a tried and tested solution.
Both product-as-a-service and software-as-a-service options create the ongoing overhead of a subscription fee by their very nature. Over time, this cost inevitably adds up, making it a more expensive offering. Another drawback is that bought options are designed as one-size-fits-all products and seldom offer flexibility for bespoke features and changes. These options offer next to no control and data ownership is often shared. This makes it hard for your users to control their privacy and hard for your chat solution to meet any needs other than the most vanilla offering.The customer service and support can also be variable. All of this creates a huge potential for complication if something stops functioning in what is essentially a blackbox solution.
Building provides you with the flexibility to create a specific chat solution for your needs and own every step in the functionality. In theory, building can be more affordable over the long-term as it reduces the ongoing costs of a software-as-a-service offering. An owned solution also minimises the risk of major changes in your chat application no longer being compitable with the rest of your application.
When building goes wrong, it is the most costly option, with high upfront and ongoing maintenance costs. Building your own chat application can run into difficulties when the app starts to scale (which is exactly when you want them least). Lastly, building something bespoke means there is no support or community to help you troubleshoot.
MongooseIM is a massively scalable, battle tested, open-source chat server that has been proven to be able to handle 10’s of millions of connections with ease. With MongooseIM you have the freedom and flexibility to use the open-source product and develop it to your needs, or you can engage our experts to build bespoke features for you. Our team also offers the peace-of-mind of support should you ever need it. This gives you the freedom and flexibility to develop and own your chat solution without the cost or risk of starting from scratch.
With over a decade’s experience in building chat applications, we know the features required to ensure a success, taking everyone from the end-user to the DevOps team into consideration. Below is a list of the most used and desired features and how MongooseIM stacks up.
It goes without saying that a chat application should allow users to reliably send and receive messages in real-time. MongooseIM’s scalability ensures that no matter what the spikes or loads of your user-base is, no important message will be lost in transit.
Push notifications are one of the most valuable parts of a modern chat application. Even if your user is not logged into the application, they’ll still be informed of the message. For B2C applications, that increases the chances of bringing them back to your app and for B2B applications, it ensures no important message goes missed, without requiring your team to be logged into a chat application at all times. MongooseIM has an in-house developed push notification management system, MongoosePush, which is designed to integrate with MongooseIM to easily enable push notifications for your chat app.
MongooseIM rarely works alone, usually it is coupled with other microservices. We offer a rest API that these services can call, and an event pusher for MongooseIM to notify them, thus providing a two-way communication with other microservices over the REST API.
An easy to use API makes your chat application faster and easier to embed and integrate into your chat. We offer a REST API, which is simple, modern and easily understood by most developers. This can be used for both backend integration and client / service development.
Group chat is one of the most popular features in social settings, and one of the most in-demand features for business collaboration. MongooseIM offers a multi-user chat functionality that is reliable and seamless for users whilst minimising demands on your server. We also provide a light-weight implementation of multi-user chat, tailored for mobile devices.
For a majority of use cases, allowing users to share and transfer files makes a chat more usable, keeping them engaged on your platform longer. MongooseIM uses an out-of-band transfer method which reduces the workload on the server side whilst still enabling an easier to use experience for users to share files within the chat application.
Batch permissions allow for privacy and control of access to information. MongooseIM uses access control lists to offer this functionality. Our chat applications have been approved by regulatory bodies in the health care and financial services worldwide.
As an application built in XMPP, MongooseIM uses the tried and tested mod_roster functionality to allow for users to manage and customise their address books within the chat application.
If something goes wrong, history and version control is vital. Having access to previous versions means you always have a proven version to fall back on. MongooseIM has a public history of its source code which you have access to at all times.
Contact sharing from within a chat application encourages connections between groups of users, helps to grow user bases and increase collaboration.
Kubernetes has become an extremely popular platform-agnostic deployment tool and has powerful cloud management automation. The MongooseIM Helm Chart makes it easy to install MongooseIM and MongoosePush to Kubernetes.
Humio is a modern log management tool that provides complete observability to your team. Our new structured logging allows you to integrate with log management tools just like Humio to identify, prevent and resolve bottlenecks, poor usage patterns in production and other recurring issues in your system.
WombatOAM is another tool to help you understand what is going on under-the-hood in your system. WombatOAM specialises in giving you visibility on the metrics of your system so you can identify trends and prevent problems arising. This includes allowing you to create automated alarms based on customisable performance metrics such as CPU usage.
In complex systems RabbitMQ can be used as an asynchronous message broker. MongooseIM is able to handle the instant messaging between users’ smartphone while RabbitMQ connects these devices to other software systems.
MongooseIM 4.0 has just been released. In this release, we’ve gone a step further to ensure an easy to use product for developers, users and a DevOps alike. Explore the changes on GitHub
If you need help with the perfect chat solution for your needs, talk to our team of scalability experts. We’re always happy to help.
It’s been busy four months. As most of us were locked in our homes, we decided to put it to use and prepare a really special release. We introduced a new configuration format, structured logging and many new features and extensions that add up to the product we are proud to share with you. MongooseIM has always empowered users to create a customised, owned chat application without the struggle of building one from scratch, now we’ve made these amazing features even more accessible and easy to use.
We want everyone to be able to benefit from MongooseIM, and so it was a rude awakening to hear the configuration described as ‘the trenches of the Somme’ by one of our users. Given we love Erlang, we hadn’t considered that its configuration might be a barrier for some developers. Once we read the feedback we knew that had to change. In the release of 4.0 we are introducing a new configuration format. For that task we’ve decided to go with TOML. Thanks to its merits we managed to get rid of most of the nested lists and tuples that sometimes were followed by a comma and at other times by a dot. We have simplified the syntax and disassembled the trenches while keeping the required configuration capabilities.
If you want to have a closer look at the new configuration format, please have a look at the Configuration section in our docs.
We all like to have the installation procedure as simple as installing a package. So we’ve made it possible to install MongooseIM and MongoosePush on Kubernetes through the Helm Chart.
You can find the Helm Charts of our organisation at the link below:
In MongooseIM 4.0 we’re introducing structured logs. This can help to have more precise and clearer structure when we query events that are logged. This is a tool you may need not often, but when you do need it, you’ll be so glad you have it because it makes it significantly easier to find exactly what you’re looking for.
If you are not yet familiar with the new OTP logger and structured logs we recommend having a look at this https://ferd.ca/erlang-otp-21-s-new-logger.html blogpost.
With the new release, we added the implementation for XEP-0215: External Service Discovery which assists in discovering information about services external to the XMPP network. The main use-case is to help discover STUN/TURN servers to allow for negotiating media exchanges.
So if you want to have a video/voice call using MongooseIM and Conversations now you can. You can use MongooseICE as a STUN/TURN relay, configure MongooseIM with mod_extdisco enabled and start having video calls between connected users.
For more details on how to use and setup
mod_extdisco and our STUN/TURN server stay tuned to our future blog posts and in the meantime, please see our documentation page: https://mongooseim.readthedocs.io/en/latest/modules/mod_extdisco/
We’ve released a new MongoosePush. In the 2.1 release you will find:
Phoenix as the Web Framework
Structured Logs, logfmt and JSON formatters
Metrics: Exometer to Telemetry, Multidimensional metrics
Many improvements in the testing pipeline
For more information on the new MongoosePush, please have a look at the release notes https://github.com/esl/MongoosePush/releases/tag/2.1.0
We released AMOC 2.1. This release focuses on the REST API, which is now powered by OpenAPI Specifications generated by openapi-generator. We’ve also significantly reworked the RestAPI so you can upload files with simple put requests. With the newly introduced documentation API for scenarios you can now check what the scenario is about before running it. Finally, the execution API was updated and now you have full control of options such as starting, stopping scenario, adding, removing users. This makes load testing even easier so you can demonstrate the value of MongooseIM to your management team.
So if you ever considered MongooseIM for your product or a project but you didn’t choose it for some reason, it’s time to give it a try. It’s the most robust, scalable and now easiest to configure Instant Messaging solution available on the market. Learn more about how MongooseIM stacks up against the competitors in terms of key considerations like costs and features in our complete guide to choosing a messaging app. Or, explore the MongooseIM page.
After working hard to get the new release live, we wanted to show off a little creative spirit. Here’s the MongooseIM’s team summary of MongooseIM 4.0 as inspired by the theme song to Friends! https://www.youtube.com/watch?v=sLisEEwYZvw
So no one told your MongooseIM 4.0 was gonna be this way
When your app’s won’t scale, you’re broke
Your XMPP life’s DOA
It’s like you’re always stuck with a single node
When it hasn’t been your day, your week, your month
Or even your year, but
MongooseIM will be there for you
(When the rain of messages starts to pour)
MongooseIM will be there for you
(When you like to configure with TOML)
MongooseIM will be there for you
(‘Cause structured logs are for people too)
The Snikket project was officially unveiled earlier this year at FOSDEM in Brussels. We’re thankful to all the great feedback we received from people who came to see first-hand what we’re building.
For people who didn’t make it to the demo at FOSDEM, what is Snikket all about?!
Snikket is actually a collection of open-source components that together form a complete messaging platform that anyone can deploy. You can think of it as a self-hosted open-source alternative to commercial messengers such as WhatsApp, Facebook Messenger, Telegram or Signal.
The primary audience for Snikket is people who want to set up their own safe, secure, and private realtime communication for small groups, such as families, communities, clubs and small businesses.
The mainstream alternatives to Snikket today are operated by commercial entities that profit from exploiting personal data gathered from their users. We believe that people should have the freedom to communicate on their own terms, rather than being forced to accept unacceptable privacy policies of a service just because their friends are using it.
We believe that everyone should have the choice of using a service run by someone that they trust. That is why we make running a Snikket server as easy as possible, and allow users of different Snikket servers to easily communicate with each other through a feature known as “federation”.
Snikket is based on the open standard messaging protocol XMPP. This means that we’re not inventing any fundamentally new technology (the world definitely has plenty of messaging protocols already!). In fact XMPP is a mature technology that has been in active developed for over 20 years. Because we are using an existing standard, there is a whole ecosystem of software that is compatible with Snikket. It also means that every Snikket server launched can immediately become a part of an existing global network of other XMPP-compatible servers.
The Snikket software itself is based on existing open-source projects. For example, the server component utilizes Prosody, and the Android app is based on Conversations. We are not forking these projects. Instead innovations that we introduce to Snikket are pushed upstream wherever possible. An example of this is the invitation based sign-up that we required to make signing up with a Snikket service as easy as possible. This involved creating a new extension to XMPP, and implementing it in multiple open-source projects, including Prosody and Conversations.
On hearing about Snikket for the first time, a question people often ask is, “why are you developing Snikket when plenty of XMPP software already exists?”
There are a number of reasons that Snikket’s existence is important.
Snikket aims to be an entrypoint for new users into the XMPP universe. This is something that a project that is just a client, or just a server, can’t do alone. We’re providing a complete package for people to get started easily even with zero knowledge of XMPP and how everything fits together.
Even for experienced users of XMPP, there are benefits to having such a package of integrated XMPP software. Knowing that Snikket client on platform A has the same set of interoperable features, same terminology, and same UX paradigms as the Snikket client on platform B makes for an attractive solution to many use-cases.
The design principles that Snikket adheres to can be found at modernxmpp.org, which is a parallel project aiming to align as many clients as possible in terms of UI/UX and protocol implementations. It is a natural extension to the Compliance Suites published by the XSF (but these only cover protocols, not features, terminology or UX).
Finally, since “Jabber” (the original user-friendly name for XMPP) is now a trademark owned by Cisco, it is unsuitable for use in many contexts and has been declining in recent years. However telling people to “use XMPP” (a protocol standard made for developers) leaves them confused and directionless. It’s a much better option to be able to tell people to “use Snikket”, which leads them to a suite of user-friendly XMPP software.
There is a lot more planned! We have two primary focuses right now: launching an iOS client, and finishing the web interface for the server (so that users can manage their account, and admins can inspect and manage the server).
4.8 for iOS should be approved soon and should start showing up in the app store soon. Since there weren’t a ton of builds for it, the mac build is being tested still and the beta has been updated. Ideally that doesnt have issues and will be released soon too .