Planet Jabber

We have identified the cause of the crash that was causing Apple to reject Monal when submitted to the Mac App Store. The root cause of the problem was the behavior of action sheet type of alerts. This was changed from a Mac style alert in Catalyst running on Catalina to the iPad popup style in Big Sur. This resulted in the OS expecting x/y coordinates for the origin of the popup and crashing. The plus side of Apple hardware is that it lasts forever. My mac mini is from 2011 and my Macbook is from 2010. With enough RAM and an SSD there wasn’t actually much of a reason to upgrade. Unfortunately, none of my machines can run Big Sur well now (even with with the hacks I use to run on unsupported hardware ) and I’ve purchased an M1 mini as a replacement. If anyone has tried to get a computer during the pandemic you know it involves waiting. I have a working solution for Big Sur while I wait for my new machine to arrive in mid Feb. This should let us catch issues in Catalina and Big Sur and prevent this from happening again.

We did a reconfiguration of our translation infrastructure, allowing translations to automatically reach the alpha build and eventually the beta and stable builds as well.

The display of missing translations and the translated percent displayed in weblate is more accurate now, too.

Please check your translations if some strings are still untranslated and update. Everyone is invited to join and make the translation even better!

Join us here: https://hosted.weblate.org/projects/monal/

Way back in 2005 some folks at Google and other parts of the Jabber community started to define a technology for setting up voice and video calls over XMPP, which we called Jingle. Unlike similar methods used in relation to SIP, Jingle enabled endpoints to dynamically gather and exchange potential connection paths for NAT traversal within context of the Interactive Connectivity Establishment (ICE). The original name for this was "dribbling" to differentiate it from the offer/answer method defined in RFC 3264 (wherein an endpoint needs to gather all of its candidate IP addresses up front before sending the offer). Over time the IETF defined a similar method for SIP, too, which we generalized under the name Trickle ICE. This week the IETF published a document cluster containing dozens of RFCs related to WebRTC, including RFC 8838 for Trickle ICE (which I co-authored with Emil Ivov of Jitsi and Justin Uberti of Google). Enjoy!...

Several people have recently reached out to me asking what kind of messenger they should be using now - they said that they actually do not understand what they should be concerned about and whether they should switch from one of the commonly known messengers to another. I wondered how to answer this. Obviously, I could simply have advocated for XMPP (Extensible Messaging and Presence Protocol), but then I thought this might not be a helpful answer by itself. Often, people just make a quick decision about their communication software and this usually isn't a well-founded choice; and so they will end up switching to yet another messenger later.

Many will actually add another messenger to their ever-increasing collection of messengers, which is likely more frustrating than helpful. This brings me back to the original question: What issue or what problem does one want to solve here? What are the incentives? Can one find a solution with a better technological basis that avoids the hype and doesn't involve installing multiple messenger apps?

Different people have different considerations for answering that question – some require effective data privacy, or data sovereignty, or simply the ability to reach all of their contacts from one place. However, moving from one messaging system to another will often mean leaving behind some contacts. Many messaging systems also require a phone number, which isn't great for privacy.

Sovereignty of Communication

As you might have suspected, I will advocate for XMPP. I think the first choice one should make is not which messenger to use, but which underlying software technology. Consider the choice of technology first, before jumping from one recommendation to the next.

XMPP is an open protocol, like HTTP is for the web. It does not matter what your website looks like, everyone can interact with it. This principle is the idea behind XMPP, but for instant messaging.

At the XMPP Standards Foundation, and with many others involved in this open technology, we think that XMPP is a great choice as a communication technology, not just with respect to data privacy. XMPP has been around for over twenty years, and a lot of practical experience has been gathered in that time. This includes many key indicators for the choice of technology and enabling sovereignty of communication, as it supports:

• Decentralization of communication services (federation)
• Standardization and extensibility of technology
• Interoperablility
• Innovation and the use of open development
• Privacy and control, also by using end-to-end encryption

XMPP provides defined information how to handle the communication in a network. The user decides which messaging software suits or where the data should be stored.

In contrast to the current situation where other people suggest you use their preferred messenger, in the XMPP universe you have a free choice of many messengers – pick whichever one you like, not what others like until the next internet fad. The difference is that, regardless of your messaging app or which app your friends use, you still have the comfort of being on the same network with all of your contacts, independent of your choice today. I think this is a real solution.

It's not about the app but about the technology

Consider a decision on the technology you intend to use, and then decide which messenger suits you or your environment. XMPP and its community have amassed a variety of experience, which has been successfully utilized in a great deal of software. We think this is a good solution for most people and organizations out there, and the internet as a whole – and it is open for all of us to make innovations for the future.

XMPP has not just a wide range of messaging software; there is also various server software and the tools (libraries) to build infrastructure yourself.

There isn't a single way communication apps must be designed. Make a sustainable decision for a standardized technology – for that purpose, and many more, we recommend the use of XMPP!

If you are interested in making a choice for the next decade, let me point you to some further reading:

• Getting started, XMPP Standards Foundation
• XSF Blog article: It’s all about choices and control from Laura, written in 2015
• Modern XMPP, website supporting developers & newcomers to get started with XMPP
• Commentary in the XMPP Community (not all in English):
  • Eine Chance für XMPP?, jabber.de
  • How to ensure your Instant Messaging solution offers users privacy and security, Erlang Solutions
  • Mastodon post, Association April
  • Twitter post, Movim Network

This blog post is published under CC BY-SA 4.0 license.

Concerns around privacy and security have become a big talking point this year. There have been a number of major Instant Messaging providers who have been criticised for the way that their apps collect, store and share the information of their users. In amongst the mountains of data collected most apps will receive information about users interests, behavioural patterns and location. Users’ privacy concerns have caused an unexpected and unwanted complication for many companies using enterprise versions of these chat applications. Firstly, if customers are turning away from the specific chat provider a business has chosen to adopt, it can create a barrier between the company and their customers. Secondly, for businesses in regulated industries such as FinTech or Healthcare, a chat provider’s ability to change their privacy and security terms and conditions is an unacceptable risk. The best way for a business to be sure that their enterprise instant messaging solution is secure and meets the privacy demands of its users is to have control of the privacy and security setting of the chat application. With most out-the-box solutions, control over privacy and security is rigid and dictated by the chat provided.

Privacy by default, customisable by design.

MongooseIM is built with maximum user privacy levels as the default, which means anyone using a standard implementation of MongosseIM has an extremely private, secure chat server that has been approved by some of the most stringent regulatory boards. On top of that, you control your chat application giving you the ability to format the settings to suit your company’s needs and your users. Below are a list of privacy considerations built into MongooseIM.

Minimise and limit

The minimise and limit principle regards the amount of personal data gathered by a service. The general principle here is to take only the bare minimum required for a service to run instead of saving unnecessary data just in case. If more data is taken out, the unnecessary part should be deleted. Luckily, MongooseIM is using only the bare minimum of personal data provided by the users and relies on the users themselves to provide more if they wish to - e.g. by filling out the roster information. Moreover, since it is implementing XMPP and is open source, everybody has an insight as to how the data is processed.

Hide and protect

The hide and protect principle refers to the fact that user data should not be made public and should be hidden from plain view disallowing third parties to identify users through personal data or its interrelation. We have tackled that by handling the creation of JIDs and having recommendations regarding log collection and archiving. What is this all about? See, JIDs are the central and focal point of MongooseIM operation as they are user unique identifiers in the system. As long as the JID does not contain any personally identifiable information like a name or a telephone number, the JID is far more than pseudo-anonymous and cannot be linked to the individual it represents. This is why one should refrain from putting personally identifiable information in JIDs. For that reason, our release includes a mechanism that allows automatic user creation with random JIDs that you can invoke by typing ‘register’ in the console. Specific JIDs are created by intentionally invoking a different command (register_identified).
Still, it is possible that MongooseIM logs contain personally identifiable information such as IP addresses that could correlate to JIDs. Even though the JID is anonymous, an IP address next to a JID might lead to the person behind it through correlation. That is why we recommend that installations with privacy in mind have their log level set to at least 'warning’ level in order to avoid breaches of privacy while still maintaining log usability.

Separate and aggregate

The separate principle boils down to partitioning user data into chunks rather than keeping them in a monolithic DB. Each chunk should contain only the necessary private data for its own functioning. Such a separation creates issues when trying to identify a person through correlation as the data is scattered and isolated - hence the popularity of microservices. Since MongooseIM is an XMPP server written in Erlang, it is naturally partitioned into modules that have their own storage backends. In this way, private data is separated by default in MongooseIM and can be also handled individually - e.g. by deleting all the private data relating to one function.
The aggregation principle refers to the fact that all data should be processed in an aggregated manner and not in one focused on detailed personal cases. For instance, behavioural patterns should be representative of a concrete, not identifiable cohort rather than of a certain Rick Sanchez or Morty Smith. All the usage data being processed by MongooseIM is devoid of any personally identifiable traits and instead tracks metrics relevant to the health of the server. The same can be said for WombatOAM if you pair it with MongooseIM. Therefore, aggregation is supported by default.

Privacy by default

It is assumed that the user should be offered the highest degree of privacy by default. This is highly dependant on your own implementation of the service running on top of MongooseIM. However, if you follow our recommendations laid out in this post, you can be sure you implement it well on the backend side, as we do not differentiate between the levels of privacy being offered.

The Right of Access

As users privacy concerns go, so too does the likelihood that a user will request to see the data that your chat application has stored on them. With MongooseIM we have put a lot of effort in order to make the retrieval as painless as possible for system administrators that oversee the day to day operations. That is why we have developed a mechanism you can start by executing the retrieve_personal_data command in order to collect all the personal and derivative data belonging to a user behind a specific JID. The command will execute for all the modules no matter if they are enabled or disabled. Then, all the relevant data is extracted per module and is returned to the user in the form of an archive.
In order to facilitate the data collection, we have changed the schemas for all of our MAM backends. This has been done to allow a swift data extraction since up till now it was very inefficient and resource hungry to run such a query. Of course, we have prepared migration strategies for the affected backends.

The Right to be Forgotten

The right to be forgotten is another one that goes alongside the right of access. Each user has the right to remove their footprint from the service. Since we know retrieval from all the modules listed above is problematic, removal is even worse.
We have implemented a mechanism that removes the user account leaving behind only the JID. You can run it by executing the “unregister” command. All of the private data not shared with other users is deleted from the system. In contrast, all of the private data that is shared with other users - e.g. group chats messages or PubSub flat nodes - is left intact as the content is not only owned by one party. Logs are not a part of this action. If the log levels are set at least to 'warning’, there is no personal data that can be tied to the JIDs in the first place so there is no need for removal.

Long term peace of mind

The recent privacy concerns of major messaging provider has created an unwanted hurdle for many businesses, but one that can be easily overcome. They do however serve as a good example of one of the broader problems with choosing an out-the-box, software-as-a-service provider for your chat solutions. Most third party products are offered as one-size-fits all, meaning any changes made by the owner will impact your account, this creates an uncontrolled liability for your business. MongooseIM offers an easily manageable alternative to software-as-a-service providers. With us, you’ll be able to utilise an extremely robust, battle-tested messaging server, that has been used by many of the world’s most used chat applications. In doing so, you’ll have a solution that is scalable, reliable but customisable and owned by your business. Learn more on our MongooseIM product page

Pushing out an update with fixed registration

As mentioned last time, there are instrumental challenges involved with tuning an electric bass in fifths, as I plan to do in order to learn the Bach Cello Suites. Classical double bassists often solve the problem of the low C by installing a special extension. On electric bass, you can tune the E string down to C but that results in a low-tension string on the bottom and therefore a flabby tone. You could also play a 5-string bass (for which the lowest string sounds a B), I suppose, but to me that defeats the purpose and I have a strong preference for 4-string basses. You could swap out the low E string for the same low B string that that 5-string bassists use, but then the action (distance between string and fingerboard) isn't quite right. A further challenge for me is that the Minotaur bass I currently play (made by luthier Joe Veillette of Woodstock, NY) is a short-scale bass, and I haven't found anyone who makes that low B string in a short-scale version (I prefer D'Addario tapewound strings on the Minotaur)....

The second Beta release of Gajim 1.3.0 fixes the most commonly seen bugs.

What’s New

Gajim will use direct messages in non-anonymous group chats instead of PMs. This is of course configurable.

Bug Fixes

• Fix a problem with the Gajim symbolic icon when opening the Accounts dialog
• Make Gajim connect even if the Private XML Storage extension is not available on the server
• #10235 Roster tooltip error
• #10342 Add Workaround for UnicodeDecodingError popups
• #10377 Profile: Make adding an Organisation entry work
• #10384 Make the HistoryManager work again in standalone mode

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

WhatsApp as we have all known it will end as a service on Feb 8, 2021. Users around the world have been presented with a screen requiring them to accept the sharing of data with “Facebook company products” or have their accounts disabled.

The new requirement to use WhatsApp

This is Facebook reneging on the promises of privacy they made when they acquired the service nearly a decade ago. For those of us who value privacy this is the final nail in the coffin. While I avoid Facebook like the plague, knowing there was a separation was one of the reasons I made an exception for WhatsApp. Partially, this was also to learn and understand what users may expect from a client. Monal today has a UI that is somewhere between iMessage and WhatsApp as a result.

I, like many others have rejected the change in terms of service. I encourage you to do so as well. I don’t need to go into what kind of toxic company Facebook is, you can go to any news site and see that. Think if you want to associate with them and remember there are other options.

Many people have gone to Signal, which is an excellent app. It is backed by some of the founders of WhatsApp and should feel very familiar to family and friends who used WhatsApp and need to flee Facebook. Signal is open source, secure, using the same cryptography code found in WhatsApp ans xmpp. The centralized nature of signal is also one of its weaknesses — the other being it’s dependency on the insecure sms network. It may seem odd to see an xmpp blog advocate for signal but you should use what your contacts are using esp. if most people you know have already decided to go there. While checking out signal, I encourage you to also encourage people to try xmpp. It has come a long way in the past 20 years and we have worked to modernize the protocol and clients. It you haven’t tried a modern client (and are expecting something like Gaim), it may surprise you.

This should also serve as a reminder of why you may want to run your own server if you know how. You can control your own destiny and wouldn’t be beholden to the good graces of the likes of Facebook for something as basic communication. We have one month before the shutoff, I suggest reaching out to your friends and family, educating and moving off WhatsApp ASAP while you can still reach them on WhatsApp.

Nobody here knew quite what a year 2020 was going to be! However despite pandemics and lockdowns, we have continued to work on Prosody. This post is a summary of how the project is doing, and what we’ve been up to in the past year.

One quick note before we begin… Prosody is an independent open-source project and exists only because the developers have been fortunate enough to be in a position to work on it. A couple of core team members are currently looking for freelance work. If you have projects in need of a Prosody expert, check the bottom of this post for more details!

More users than ever before

Prosody does not “phone home” in any way, which means we do not have a lot of insight into how many people are using Prosody. But there are some indicators that we can use to see at least the growth of the project.

Many years ago, circa 2014, I was filling out a form that asked how many users the project had. I thought long and hard, but with no idea how to measure, I wrote down an estimate of “500” based on nothing but a gut feeling. Only a few weeks later I learned that the XMPP Observatory had already seen over 2200 domains submitted that were running Prosody. As most deployments were unlikely to have been submitted to xmpp.net, my estimate was clearly far out. These days I jump at any chance for even a vague estimate of our userbase. It helps us to know that people are out there!

One useful tool is Shodan. This project scans the entire internet, just to see what it can find, and it records the results. Often used by academics and security researchers, a free account can also be used by anyone to run simple queries over the data they collect.

A Shodan search in 2017 turned up nearly 7000 Prosody deployments. The same search 8 months later returned over 16000. Today we’re at over 52000 Prosody servers! And this only counts instances using port 5269 and accessible to the internet. There are also many private/internal deployments of Prosody that are not included in these numbers. Unfortunately we didn’t run a report in 2019, but here’s a graph of the previous reports we have run:

Shodan reports over 85000 federating XMPP servers on port 5269 in total. Based on this, Prosody makes up 44% of the public XMPP network. That’s quite an achievement!

Another handy insight into one sector of Prosody deployments is via Debian’s “popularity contest” service. This is an automated survey that administrators of Debian servers can choose to opt into. It reports anonymously to Debian what software packages are installed and in use. Although it reflects only a small slice of even Debian installations, it is useful to see trends.

March 2020 marked an unprecedented spike in Prosody installations!

Although we don’t know for certain, we suspect this was caused by an surge of interest in the self-hosted video conferencing software, Jitsi Meet. Jitsi Meet integrates with Prosody, which is used to power the authentication, signaling and chat of the video conferences. Jitsi’s Videobridge component handles the media routing. Together they make a very powerful and flexible communication system, and it is hardly surprising that interest has spiked this year when there has been a massive shift to remote work, and online meetings have replaced physical ones.

The code counts

Now let’s look at some stats about the Prosody codebase itself.

Language	Files	Code	Comment	Comment %	Blank	Total
Lua	295	48358	3536	6.8%	6483	58377
C	13	2613	346	11.7%	643	3602
Other (build tools, etc.)	11	1551	22	6.3%	138	1711
————————-	——	———-	———-	———-	———-	———
Total	323	54760	3909	6.7%	7265	65934

Changes in 2020

In 2020 (looking at the development branch) we added 597 commits, changing 191 files. The changes added 9872 lines of code, and 3637 lines of code were removed.

A significant portion of the new lines were in our unit and integration tests (2200 lines, about 22%) which we have been working hard to expand over the past couple of years.

Community modules

If you use Prosody, you know we have an emphasis on modularity and extensibility. We like to make developing plugins for Prosody as easy as possible, whether it’s for integration with other systems or crazy experiments.

Here’s a random selection of the 363 modules currently in the repository:

mod_muc_eventsource

Receive messages from MUC rooms with 4 lines of Javascript

mod_log_ringbuffer

Send debug logs to RAM unless they are needed.

mod_component_client

Allow a Prosody server to run as a (XEP-0114) external component of another (Prosody or not) XMPP server.

mod_firewall

Powerful rules-based scripts for filtering and redirecting XMPP traffic.

mod_minimix

An experiment in making MUC joins persistent (like MIX).

During 2020 we saw 37 new modules published in the community repository, and 499 commits from 19 contributors. Together they added over 10,000 lines of code (and removed 728 lines). This makes it our most active year apart from 2018!

Outside of the Prosody dev team, the most active contributor was Seve, who also made their first contribution this year and added a total of four new modules. Welcome aboard!

Features

But the most important part… what features have we been working on? All these things are scheduled for the 0.12 release (more on that in a bit).

Plugin installer

We have been applying further polish to, and setting up the infrastructure for the plugin installer. This was a Google Summer of Code project by JoĂŁo Duarte. It utilizes the Lua package manager, LuaRocks, to download, install and manage community modules.

Although the the installer was completed in 2019, to make it generally usable we also had to ensure every module in the community repository could be packaged and served in an automated way by our server. We now have this working.

Bye bye telnet, hello prosodyctl shell!

The telnet console is one of the best things about Prosody, and we’ve been working on its successor. An early version of prosodyctl shell is already available to try out in trunk nightly builds.

Using prosodyctl allows us to more easily support advanced features such as line editing and history (previously attainable using a third-party utility, rlwrap). It also allows for some richer UIs and is more secure on shared servers (it uses a unix socket instead of TCP).

DNS improvements

Since Prosody needs to resolve special DNS record types (such as SRV records) and in an asynchronous manner, the built-in operating system APIs are generally inadequate.

For a long time we’ve been using an adopted library simply known as ‘dns.lua’ combined with our own asynchronous wrapper around it. Although it hasn’t been terrible, it has a few issues, especially in some uncommon environments. It also doesn’t support many advanced features such as DNSSEC.

Now we are migrating to libunbound, part of the unbound project. This is one of the leading DNS implementations, and will be a big improvement over our current DNS library. To try it out, you can simply install luaunbound (already available in luarocks, Debian testing, AUR and others - poke your distro maintainers if you don’t have it yet!).

HTTP server upload performance

We didn’t set out to write a HTTP server, but we ended up with one anyway! Originally added so that we could natively support BOSH (XMPP over HTTP) clients, it grew to support websockets, and various modules now provide HTTP APIs for integration between Prosody and other systems.

One big problem is that the original implementation was designed for only small amounts of data. Since the widespread of adoption of XEP-0363 people now want to be able to upload files, pictures and videos using Prosody’s internal HTTP server. We have limits in place to protect against denial of service attacks, but those same limits prevent large uploads from trusted users.

We’ve put some work into supporting “streaming uploads”, where incoming data can be saved directly to disk instead of RAM. This means it will be safe to increase file upload limits without opening up your server to increase RAM usage and denial of service attacks.

In general though, we do recommend using a real external HTTP server in a production or high traffic deployment (using mod_http_upload_external).

Beyond passwords

Passwords are the fundamental means of authenticating to your server in XMPP today. XMPP is quite good at this, adopting strong standard authentication mechanisms such as SCRAM far earlier than the rest of the industry. But the rest of the industry is also moving away from passwords in many places. We’re aiming to follow this movement also. Not that we are scrapping passwords entirely, but making it easier to offer alternatives.

Prosody actually has a number of non-password authentication modules already, such as mod_auth_oauthbearer (OAuth2 tokens), mod_auth_ccert (client certificates) and mod_auth_token (HMAC-based tokens). But most of the modules have limitations and are not well integrated (e.g. you can set up Prosody to accept passwords, or set it up to accept tokens, but you can’t offer both methods at the same time).

An important related aspect is authorization. In most systems authentication via a token also provides limited access to the account (e.g. if a password is associated with an account, a session that logged in using a token should not be allowed to reset the password).

We’ve been working on two things. Firstly, a built-in authorization system (more flexible than the current admins configuration option) where users and sessions can be associated with specific permissions and roles.

Secondly we’re using this authorization layer to add built-in support for OAuth2-style authentication and authorization.

This is exciting for a number of reasons. It will allow, for example, specialized clients to request and receive (when granted by the user) limited access to an account without giving it your password. Some example scenarios could be:

• Allow a third-party service to send messages via your account, but not access your contacts or message history
• Allow an account backup/migration tool read-only access to your account without giving it your password
• A specialized client could be granted access to only specific types of incoming messages. For example a chess game that used your XMPP account to communicate with a remote player, but wouldn’t be able to read your IM messages.

We’re still working out the details right now, but the expectation is that some of these features may require or be enhanced by extensions to the XMPP protocol. Once we have some implementation experience, we will standardize such extensions as XEPs. That way we can open the door to a world where every XMPP client doesn’t require a password, and doesn’t automatically get full access to your account.

The boring branches

All the above work has been happening in our trunk branch (nightly builds are available, by the way! ). But we are also maintaining our 0.11 stable branch with bug fixes.

In 2020 we made 98 commits to the 0.11 branch, and made 4 releases. The latest version is 0.11.7, and 0.11.8 will be coming soon.

We also have two other branches open - 0.9 (old old stable) and 0.10 (old stable). We have a soft policy to keep supporting our branches while they are in an active Debian release. Debian stable is on 0.11.x, and the previous Debian release (stretch) was on 0.9.x and stopped receiving security updates from the core Debian team in July. As such, we will be formally deprecating these branches shortly.

In summary: if you are not on 0.11.x already, get moving :)

Not to be missed…

Through 2020 we put a lot of attention into helping increase adoption of XMPP and helping it reach new users. This includes the launch of our sister project, Snikket at FOSDEM, and the backporting of Snikket’s invite-based registration to generic Prosody deployments.

Up next: Prosody 0.12

We’re currently working towards the next major release of Prosody. It’s a lot of work to polish off all the new features and get them sufficiently tested and documented. We are likely to start with a beta or release candidate in the coming months.

Many thanks to all the testers of the Prosody trunk nightly builds, who provide valuable feedback and deployment experience.

Available for hire

Prosody has been in active development for over a decade. Over this time we’ve deliberately strived to keep the core project free from any commercial influence or activities. We believe that this helps keep the project focused on what the community wants, instead of simply what people with money want :)

That said, we also need to pay our bills so we can continue to work on Prosody. Two members of the dev team are currently available for freelancing on a full or part-time basis for any size project. We do strongly prefer projects related to Prosody/XMPP, and open-source if possible.

Whether you want to hire us to integrate Prosody with your application, review your architecture, or develop a new feature in Prosody itself, get in touch. You can reach us at developers@prosody.im.

Finally, we hope everyone is having a great start to the new year. That’s all for now. Stay healthy!

Kaidan will be supported by NLnet for adding end-to-end encryption support. We will implement the latest version of the encryption protocol OMEMO and extend it by an easy trust management to solve issues other OMEMO-capable chat apps suffer from.

Fundamentals

End-to-end encryption ensures that sent data can only be read by the intended recipients. Signing is used to ensure that received data comes from the intended sender and was not modified in transit. To read encrypted data, it has to be decrypted before.

Keys are used to encrypt and decrypt data. Those keys are like very strong passwords. If the data is encrypted and decrypted with the same key, the procedure is called symmetric encryption.

OMEMO enables the users to chat end-to-end encrypted. It is an asymmetric encryption protocol. That means, different keys are used to encrypt and decrypt the data. Each communication partner has a private and a public key. A private key is used to sign and decrypt data. A public key is used to encrypt data and verify its signature.

Metadata

The latest version of OMEMO uses Stanza Content Encryption. That means, in addition to messages and files such as images, it is now possible to end-to-end encrypt metadata as well. Such metadata could be e.g. the indicator whether someone is currently composing a message. Kaidan will use Chat State Notifications for that purpose and encrypt them with OMEMO. Furthermore, many features already supported, like delivery receipts and message correction, are going to be automatically end-to-end encrypted.

Trust Management

When a user starts an encrypted chat, OMEMO retrieves the recipient’s public key automatically. Since there is no secure channel yet, that key might not belong to the intended recipient but to an attacker controlling the infrastructure in between. Trust management is the process of deciding whether a retrieved public key should be trusted and thus used for encryption and signature verification. Trust Messages in combination with Automatic Trust Management simplify the trust management.

Nowadays, it is possible to use OMEMO relatively hassle-free with several XMPP clients but the trust management is still complicated. It becomes even more difficult when someone uses a new device. With Automatic Trust Management, Kaidan will be the first XMPP chat app introducing an easy trust management. It automates as much as possible while keeping the same security level as with a completely manual trust management.

Free and Secure Communication

As far as we know, there are no other implementations of Stanza Content Encryption and Automatic Trust Management in use at the moment. We will take the first steps and hope that other XMPP developers will follow our lead. XMPP client developers interested in implementing an easy trust management should have a look at ATM’s project site. It contains all relevant links, pseudocode and test cases.

Kaidan’s goal is to minimize the effort for establishing free and secure communication, thus lowering the entry barrier to strong encryption mechanisms for the average user. NLnet and a couple of other organizations support us via the NGI Zero PET fund to achieve that. The money is provided by the European Commission. That is a great example (like the previous support by the DBJR (German Federal Youth Council)) of how public money can be used to develop free software.

There are many other interesting projects currently funded by NLnet. We are glad that Kaidan is one of them!

The Ignite Realtime Community is pleased to announce the availability of version 4.6.1 of it’s Realtime communications server Openfire!

This version is largely a bugfix release. It primarily focusses on improving multi-user chat and pubsub functionality when running an Openfire cluster, but also includes other improvements, such as LDAP/AD preformance enhancements. You can find all changes in the changelog, which is denoting 33 issues resolved since 4.6.0.

We are again grateful for all of the support that was provided to us, in no small amount through our community that is active in our chatroom and on our community forums!

We invite you to give this release a try. The process of upgrading from an earlier version is as lightweight as ever. It is outlined in the Openfire upgrade guide. Please note that, if desired, a significant amount of professional partners is available that can provide commercial support for upgrading, customization, or other services.

We’re always happy to hear about your experiences, good or bad! Please consider dropping a note in the community forums or hang out with us in our web support groupchat.

Download artifacts are available here with the following sha1sum values:

8fe60c2ac0be32f497648a6f129dec89ec858533  openfire-4.6.1-1.i686.rpm
c7e949d21aecb488617c8effe31f5831d25ed912  openfire-4.6.1-1.noarch.rpm
a28e01c896d40f756a03c2e7cf8ec48ef45af782  openfire-4.6.1-1.x86_64.rpm
6504c08821415e8e053ca361f78e899f6c9ddf7e  openfire_4.6.1_all.deb
2d76d5ead560b49dda95cf9305e9d47f67ef2349  openfire_4_6_1_bundledJRE.exe
1423d1aa5ca6d9e4169b5f775bc11b5f6b4fcf8c  openfire_4_6_1_bundledJRE_x64.exe
a4c7f7d4bd82d2eecf6791befcc8285d172740ad  openfire_4_6_1.dmg
627d062dec364bc2f4e6a8b54d171c599525edde  openfire_4_6_1.exe
84915336194c72622d96b9a0a20d9418397b93d6  openfire_4_6_1.tar.gz
89c6cf5ff54718eefee21292dc63f304ed8d6e2c  openfire_4_6_1_x64.exe
8be2dcb848cd501f20bff285ffa68a824d5f7d32  openfire_4_6_1.zip
602f9b6dc2f3b95cb25decf1026196d9b4a4c348  openfire_src_4_6_1.tar.gz
8354eb3fd548221bd76f5d5096766e04bbed36be  openfire_src_4_6_1.zip

Thank you for using Openfire!

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

The Ignite Realtime community is happy to announce the release of version 2.2.0 of the Monitoring plugin, which provides support for chat archiving and server statistics to Openfire.

This update includes a good deal of improvements and bug fixes. Notable are:

• Improved stability when running as part of an Openfire cluster.
• Bugfixes in the Message Archive Management (XEP-313) implementation.

Starting with this release, the message archive functionality is fully based on the database tables maintained by this plugin again (in previous versions, the message archive for multi-user chat rooms were based on database tables managed by Openfire itself). This change might different identifiers to be used for messages in MUC archives, which might affect clients that have previously interacted with earlier versions of this plugin. Our tests with various commonly-used clients did not show any relevant functional issues stemming from this.

Your instance of Openfire should automatically display the availability of the update. Alternatively, you can download the new release of the plugin at the Monitoring plugin’s archive page.

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

Many questions arise when considering how to climb the mountain of playing Bach's Cello Suites on electric bass. One of the key questions is the question of keys. The original keys for the six suites are G major, D minor, C major, E♭ major, C minor, and D major respectively. Other than the fourth suite, these keys lie naturally on the cello, which is tuned in fifths and whose open strings (from lowest to highest) are C-G-D-A. Thus five of the six suites can benefit from the harmonic resonance of open strings, which is especially important when playing the suites on a Baroque cello. (Those who play in a more Romantic style don't like the notes of the open strings because you can't generate the requisite vibrato.)...

Wonder is what I've long felt about Bach's Suites for Unaccompanied Cello. I'm not sure when I first heard them, but over time they have become ever more meaningful to me. I regularly listen to various recorded renditions; some of my favorites are by Stephen Isserlis (cello), Patricia McCarty (viola), Edgar Meyer (double bass), Michael Nicolella (guitar), Jean-Guihen Queyras (cello), Hopkinson Smith (lute), Janos Starker (cello), and Pieter Wispelwey (cello). So far, that is - I'm actively adding more recordings to my collection as I explore these works ever more deeply....

Apparently I got out of the habit of writing a brief "annual report" for the Monadnock Valley Press, under whose auspices I both post public-domain texts (at monadnock.net) and publish the philosophy books I write on the side. So it's about time to remedy the oversight, since the last report was for 2016....

More than four months have passed since the release of Gajim 1.2.2. A lot has happened during this time, including a complete redesign of both Gajim’s Preferences window and configuration backend. Be the first to have a look, and help us ironing out the last issues before the final version arrives.

What’s New

A huge amount of code has been cleaned up around Gajim’s configuration backend. This was necessary in order to move from a configuration based on text files to a new settings backend powered by SQLite. Gajim is now able to store settings efficiently, and some quirks around default values have been solved. After all these changes under the hood, it was time to redesign the Preferences window. The redesign enables us to display settings in a tidy and clear fashion, which should make it easier for you to handle all of Gajim’s configuration possiblities.

Gajim’s Notification settings for event handling have been split up. You can now decide if you want notifications to be shown in general, and if you want new messages to be opened directly (without a notification icon in the contact list). All settings around sending Chat States (e.g. ‘Composing…') have been moved from the Preferences window to the Accounts window, completing the migration of account-related settings. Gajim uses a ‘Sync Threshold’ setting to decide how many messages should be synchronized when joining a chat. If you set a custom Sync Threshold previously, please make sure to check the setting after upgrading Gajim, since it could not be migrated.

These changes are touching many parts of Gajim’s code base, and migrating all of your settings is a complex task. In order to resolve possible issues in the migration process, we offer a Beta version for curious testers to play with. There are many more changes coming with Gajim 1.3.0, which will be covered once the final version arrives.

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.

There were no show stopping issues with the last east beta and I have submitted Mac 4.9 to the App Store. The update should be available in a couple of days depending on app review times.

2020 has been a year of remarkable growth for this project thanks to the efforts of Thilo, Friedrich and emus. We hope to release 5.0 with even more improvements in 2021

Happy new year!

Despite pandemic lockdowns and such, I read only ~75 books this year (granted, a third of them were dense works of philosophical scholarship on Aristotle). In 2021 I hope to finish the remaining dozen or so books I need to read in preparation for writing an epitome of Aristotle's ethics; I also hope to include a more generous helping of literature, modern science, and history. Several of the following books are available online at monadnock.net (the site where I post books that are in the public domain); see the end of this post for links....

There has not been a major release of the MatriX XMPP library for some month. I am working hard on the next major update and want to give a small summary on whats coming.

There are some huge changes in the latest .NET releases. The effort to combine legacy .NET, Xamarin, MONO and netCore to one unified platform is super exciting.
With the current netStandard version of MatriX vNext there are still some issues sometimes when MONO based platforms like Xamarin or Unity are targeted. There are still many corner cases where MONO behaves different than .NET.

Updating to .NET 5 is an easy task, but at the same time I want to take the opportunity for a redesign of some internal components. And one of the major goals for the next release is support for WebAssembly projects with the Blazor framework. Blazor support is only possible with major changes in the networking stack and adding Websockets as a transport option.

Here is a small summary on what coming with the next major MatriX vNext release

• update to .NET 5.0
• remove DotNetty dependency and replace with custom networking code
• build better abstractions for networking code and build transports as plugins
• add WebSockets support
• WebAssembly support with Blazor framework
• better Xamarin iOS and Android support which comes more or less for free from the previous changes

I made huge progress and have working tests client for Blazor WebAssembly. But the code still needs some cleanup and more integration and end 2 end tests. The source code and beta packages should be available on GitHub soon.

Contact me when you are interested and need early access.

Stay tuned…

For the upcoming Monal 5.0 we want to introduce a new app icon.

Of course we want to know what you, the users, think about this new icon:

Feel free to fill up the comment area below

I have been auto posting Monal updates to twitter for a while. If you do not use twitter and use reddit, you may want to join the new Monal subreddit. Ideally this would be easier to follow than a twitter thread and a place to discuss Monal issues and enhancements

In December, the profile window received a complete rework, adding state of the art vCard capabilities and a brand new profile picture selector to Gajim. Furthermore, Chat Markers have been improved and some bugs have been fixed.

Changes in Gajim

Gajim’s Profile window received a complete rework. This includes a new backend using up to date standards (XEP-0292 vCard4 Over XMPP), as well as a completely rewritten dialog for displaying and editing vCards. The new Profile window uses a so called VCardGrid, which enables Gajim to display vCard contents. This VCardGrid also offers editing capabilities, enabling users to modify their own vCard. Since this works perfectly for viewing vCards, we plan to use it in the Contact Info window as well.

A big advantage over the old Profile window is that you can add (almost all) elements more than once. For example, you can add an email address for your workplace, and additionally a private one. Or multiple organisations, or even more PGP keys, … All these elements are added dynamically, there is no static user interface here.

Selecting your own profile picture is much more fun if you can crop it directly using integrated tools. This is now possible using the new picture selector, which enables you to select the detail you want to show, using a fixed aspect ratio.

This completes one of the last missing steps before we can finally release Gajim 1.3.

What else happened

• Improved both Chat Marker and Message Receipt icons
• It’s now possible to programmatically send files via HTTP File Upload (XEP-0363) without sending a text message
• Added back metacontacts_enable advanced setting
• Fixed a bug occuring if Idle Monitor is not available (#10295)
• Fixed a bug where the Preferences window did not expand correctly on Windows (#10359)

Plugin updates

Gajim’s Flatpak plugins have been updated.

Changes in python-nbxmpp

While finishing Gajim’s new Profile window, python-nbxmpp received functions to set the PubSub (XEP-0060) access model for your nickname and avatar. These are necessary for making both nickname and avatar either public for everyone or just for your contacts.

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

The next beta for Mac has been released. This adds the ability to send location from the attachment button and bring it to feature parity with iOS. Barring any last minute issues this will be the version send to apple for release.