Planet Jabber

January 24, 2021

Monal IM

Update on Mac App Store release

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.

by Anu at January 24, 2021 03:39

January 23, 2021

Monal IM

Translations reworked

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/

by Thilo at January 23, 2021 20:10

January 21, 2021

Peter Saint-Andre

RFC 8838: Trickle ICE

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!...

January 21, 2021 00:00

January 20, 2021

The XMPP Standards Foundation

Instant Messaging: It's not about the app

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:

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

by Edward Maurer at January 20, 2021 05:30

January 18, 2021

Erlang Solutions

How to ensure your Instant Messaging solution offers users privacy and security.

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

January 18, 2021 15:19

January 13, 2021

Monal IM

4.9.1 with reg fix

Pushing out an update with fixed registration

by Anu at January 13, 2021 15:46

January 12, 2021

Peter Saint-Andre

Bach on Bass #3: Instrumental Challenges

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)....

January 12, 2021 00:00

January 09, 2021

Gajim

Gajim 1.3.0 Beta2

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

Gajim

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

January 09, 2021 00:00

January 08, 2021

Monal IM

The end of WhatsApp is an opportunity

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.

by Anu at January 08, 2021 15:20

Prosodical Thoughts

How Prosody developers spent 2020

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:

Graph of Prosody server counts in previous paragraph

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!

Graph of Debian popularity contest data for prosody

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!

by The Prosody Team at January 08, 2021 00:00

January 07, 2021

Kaidan

Kaidan will receive a grant for end-to-end encryption

OMEMO logo

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!

January 07, 2021 13:00

January 06, 2021

Ignite Realtime Blog

Openfire 4.6.1 is released

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

by guus at January 06, 2021 13:35

Monitoring Openfire plugin v2.2.0 released

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

by guus at January 06, 2021 12:40

Peter Saint-Andre

Bach on Bass #2: Keys and Tunings

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.)...

January 06, 2021 00:00

January 05, 2021

Peter Saint-Andre

Bach on Bass #1: Wonder

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....

January 05, 2021 00:00

January 03, 2021

Jérôme Poisson

SàT progress note 2020-W53

Happy New Year!

It's been a long time since the last progress note, and things have been moving.

First my apologizes for not releasing SàT 0.8 at the end of 2020 like I was expecting: I'm willing to polish some features before releasing, notably in Libervia (web frontend), and I thought that it was best to wait a few more months. I'll try to release more often in the future.

Let's have a high level overview of what has been done since last progress note.

invitations

I've been working on Libervia UX for invitations. SàT implements an invitation system to easily share an activity (photo album, event, or anything). Here "sharing" means sending a notification, and giving access to somebody. The invitation can be sent to somebody in your contact list by entering some letter of his/her name, somebody external by providing the full jid, or somebody without XMPP account by sending an invitation by email. It's only a few click, and access can be removed just by clicking on the deletion cross. I believe that this is a major feature to use easily this as a familial social network.

Photo album invitation in Libervia

Docker integration

You're probably wondering what Docker has to do with an XMPP client (installation put aside). Well, the are several reasons why it's really useful, the first one is to integrate third party software into frontends like Libervia.

As you may know, we are dogfooding most of the development tools with SàT and XMPP (things like tickets/bugs reports are managed with it). So far, there was no translation application used, and translations were done using desktop apps like Gtranslator, which is good but not so easy to install for contributors. With the new Docker integration, Weblate can be added in Libervia with just the following setting in sat.conf:

menu_extra_json = [
    "sat-app:weblate"
  ]

With this simple setting, a new "translate" menu will appear in Libervia and Weblate will be there:

Weblate integrated in Libervia via Docker

The application needs to be integrated with SàT, this is done in a YAML file: here the official Weblate Docker image is used, and SàT settings are re-used when possible to make the process as easy as possible (for instance the configuration to send email is re-used automatically). Note that Docker is currently used, but the plugin managing this is made in such a way that other tools can be used in the future (maybe LXC, systemd-nspawn, Python's virtual envs or something else).

For now it is "weak" integration, Weblate has its own accounts/login. If one day we have the resources, it would be great to work on deeper integration with single log-in (and maybe contributing XMPP login upstream), and a theme adapted to Libervia's one.

An other application I plan to integrate this way is Jitsi Meet: at the moment I have not the time to work on video conference, and Jitsi is really good, handles multi users calls, and uses XMPP too. Integration of Jitsi is a good way to have video conferences quickly in Libervia, until it's possible to find the time to do a native implementation.

End to end tests

The second reason why Docker integration was useful is for end-to-end tests. Historically SàT has been tested with Twisted's trial tools, and there was a Buildbot installation. But with time and lack of resource, this has been unmaintained, and it would have been lot of work to put that back in shape.

Thus I've restarted fresh and I'm now using the popular pytest framework. I've decided to focus on end-to-end tests as it's a way to check the whole ecosystem (including SàT PubSub). For now, tests are done with "jp" (the CLI frontend) and Libervia. For the former the sh module is used with the help of pytest's fixtures, this way tests are really easy to write. For Libervia, I've gone with Helium which is a high level module to use Selenium. The only worry I have is that I'm not sure if Helium will be maintained on the long run, but it should not be a big deal to switch if necessary, and it makes some things easier (notably drag and drop simulation).

Above that there is a little script to make it easy to run the tests, with an option to launch a VNC viewer to follow Libervia tests in real time (check documentation for details). I have long term plan to integrate that in Libervia next the to the source code, in a way similar as what you may see on popular code forges (like Gitlab).

That was also the occasion to rework SàT and Libervia's Docker images. There is still some polishing and documentation to do, but it should be fine for the release.

Full-Text Search for PubSub

One of the last major feature I wanted to implement before the release is Full-Text Search in PubSub. This is using the namespace specified in XEP-0431 and implementation is done in SàT PubSub (the generic PubSub component developed in parallel of SàT to be sure to have all needed features). You can see the result on this blog with the new "search" bar.

the new search box use PubSub Full Text Search

PostgreSQL's FTS engine is used, and it is possible to specify the language of the content. For instance if a blog is known to be in English, you can set the fts_language setting of the node to english. This is needed for improved results because it lets PostgreSQL use the right canonical form of the word. The canonical form of a word is a common root used for variations (like singular/plural, or verb conjugation). Thanks to this, the search will return articles which contain progress note in this blog, even if you search for progresses in plural form.

By default a generic language is used (which correspond to PostgreSQL's simple dictionary), which works with everything but has lower results.

The implementation has been thought to make it possible to override the language used per PubSub item (but it is not yet used). This will be useful for multilingual pubsub nodes like this blog (which is written in French and in English).

The neat thing with having that in PubSub is that it is now available out of the box for all PubSub based feature. So Full-Text Search is now also available in ticket handlers too (like SàT's bug tracker).

SàT advanced features are now usable with generic PubSub services

For features like tickets handlers or merge requests, a SàT PubSub specific implementation has been initially done to manage "Node Schema", i.e. a way to attach a data form template to a node (to indicate how data are organised, and to reject invalid items).

After announcing the ticket feature years ago, I've got a message mentioning XEP-0346 which I've missed at the time. This XEP has the advantages to work without modification on a generic PubSub service. It is now implemented in SàT and SàT PubSub, and thus all features should work with any standard implementation of PubSub. SàT PubSub is still recommended though, as it implements features like Order-By or serial ids which improve user experience and are rare or nonexistent at the moment in other implementations.

many other things

I won't list all the things done since last progress note since there are too many. But in brief, I can tell that XEP-0353: Jingle Message Initiation has been implemented, this is useful to send a file using a bare jid and improves UX a lot, thumbnails of videos are generated (notably useful for photo album), a loading screen is now shown in Libervia to avoid unresponsive actions if JavaScript is not fully loaded, there are new jp commands, bug fixes, etc.

Anyway it's enough for this time, see you soon.

by goffi at January 03, 2021 17:09

January 01, 2021

Peter Saint-Andre

Monadnock Valley Press Annual Report 2020

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....

January 01, 2021 00:00

Gajim

Gajim 1.3.0 Beta

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.

Gajim’s new Preferences window

Gajim’s new Preferences window

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

Gajim

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

January 01, 2021 00:00

December 31, 2020

Monal IM

Mac 4.9 submitted and 2021

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!

by Anu at December 31, 2020 20:31

Peter Saint-Andre

2020 Readings

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....

December 31, 2020 00:00

December 30, 2020

Alexander Gnauck

MatriX vNext development update

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…

by gnauck at December 30, 2020 17:05

December 29, 2020

Monal IM

New App Icon

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 🙂

by Thilo at December 29, 2020 06:58

December 28, 2020

Monal IM

Monal subreddit

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

by Anu at December 28, 2020 04:53

Gajim

Development News December 2020

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.

Gajim

December 28, 2020 00:00

December 27, 2020

Monal IM

Mac 4.9 beta 2

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.

by Anu at December 27, 2020 03:37