The following changes are ready to be tested in Monal 5. The Mac build is up for download here and iOS will be available on TestFlight soon. The Mac build address has been updated to a tar.gz file instead of zip. It should open the same. The link has been updated to use the new macOS name as well.
omemo to/from siskin/beagle now functional
showing of own omemo key qr codes for quick verification
persistence of trust levels even if omemo errors occur
qr code scanning for macOS
fixed crash on account deletion
don’t allow change of account jid
many small fixes
push server now uses xmpp for registering new push tokens (now the monal appserver never sees your ip)
catalyst (especially on apple silicon) now has real push support
February brings many bug fixes for the upcoming Gajim 1.3.1 release. The Profile window’s error handling has been improved, and selecting small images for an avatar should now work as expected. While fixing those bugs, we’ve been working on something big.
Changes in Gajim
Roughly a month ago, we started a rework of Gajim’s main window. This will bring fundamental changes to Gajim, but it will also take some time until it’s ready to be shown. Many core functionalities are tied to the ‘roster window’, which displays your contact list. This is due to Gajim being grown around the contact list acting as the main entry point for almost every action. Currently, we’re in the process of untying those functionalities in order to separate them from the contact list. While this work happens mostly in the background, we managed to fix a good portion of new bugs which showed after the release of Gajim 1.3.0. Thanks everyone for reporting issues!
What else happened
Added setting to explicitly enable GSSAPI authentication
Added account badge for group chat invitations #10424
Removed ASCII Emoji replacing mechanism for incoming messages (Gajim now displays them as intended by the sender)
Better error handling for the new Profile window
Improved avatar selector (works now for images <100 px)
Account Creation: Links offered by servers during registration are now clickable #10445
Gajim now displays an error if gateway registration fails #10443
Fixed horizontal scrollbar sometimes appearing in the chat window
Fixed crash which appeared when trying to open the Contact Information window for offline contacts #10273
Fixed crash occurring when clicking a ‘connection failed’ notification #10436
Fixed rare crash which occurred when disabling video preview in preferences #10430
Plugin updates
Gajim’s URL Image Preview plugin now respects EXIF rotation when generating previews.
Changes in python-nbxmpp
python-nbxmpp 2.0.1 and 2.0.2 have been released, addressing multiple bugs. GSSAPI authentication has to be enabled explicitly, since it could lead to complications when other mechanisms are available as well. Furthermore, an issue with the publication of avatars has been fixed.
with support from Anu & Thilo I am organizing the community project to redesign the Monal logo. After the suggestion’s have been made we would like to ask the community to vote and what should be done. No worries, there will be the option to keep the current one, if a majority votes for this.
There are a few criteria:
– Have a similar coloring scheme
– Try to keep it suitable to the Monal name / “brand” and for the community
– You agree to publish this under the same license as Monal is and do not use material that has copyright not enabling the use in this project
– Provide it as SVG file (it is not are hard criteria but would be really helpful for us!)
– Please hand in before the **31st of March 2021**
Please publish your suggestion on Github. If you have multiple suggestions or versions please post each in a separate comment. If you don’t have the option to publish on Github, please reach out to the developers.
We will likely call for final voting outside of GitHub, but feel free to us the platform vote function. Please respect the work of other, if you like it or not.
We are pleased to announce a new minor release from our stable branch.
A new release appears! This time it includes bug fixes and performance
improvements!
Thanks to the Jitsi folks for helping us improve websocket performance
in this and the previous release.
This release also fixes a security issue, where channel binding, which
connects the authentication layer (i.e. SASL) with the security layer
(i.e. TLS) to detect man-in-the-middle attacks, could be used on
connections encrypted with TLS 1.3, despite the holy texts declaring
this undefined.
A summary of changes in this release:
Security
mod_saslauth: Disable ‘tls-unique’ channel binding with TLS 1.3 (#1542)
Fixes and improvements
net.websocket.frames: Improve websocket masking performance by using the new util.strbitop
util.strbitop: Library for efficient bitwise operations on strings
Minor changes
MUC: Correctly advertise whether the subject can be changed (#1155)
MUC: Preserve disco ‘node’ attribute (or lack thereof) in responses (#1595)
MUC: Fix logic bug causing unnecessary presence to be sent (#1615)
mod_bosh: Fix error if client tries to connect to component (#425)
mod_bosh: Pick out the ‘wait’ before checking it instead of earlier
There is a significant difference between developing and promoting a
protocol (such as XMPP) and a product (such as Signal). Both approaches
have their advantages and disadvantages. This post details how and why
Snikket aims to strike a balance between the two.
Products vs Protocols
This past weekend I gave a talk at the (virtual) FOSDEM conference about
a topic I’ve been thinking about a lot the past few years - the differences
between developing a product and developing a protocol.
You can watch the talk here, but there were many things I
wanted to touch upon that wouldn’t fit into the 20 minute slot. This post
will cover the same topics, but expands on some of the points I
discussed.
Previously, in open protocols…
I’ve been involved with XMPP (once known as Jabber) for over 15
years. It is now over 20 years since XMPP’s inception, and over this
time XMPP, along with the rest of the tech industry, has seen significant
change.
XMPP began life in the late 1990s, as an attempt to break into the
messaging silos of that era. The names and logos may have been different,
but it was a very similar landscape to today - oversized tech companies
fighting each other for control over people who simply want to use the
internet for what it was designed, communicating with one another.
Email got lucky. A standard protocol managed to break down the walls of
even the final fortress of resistance, AOL. This was achieved largely
because the adoption of standard protocols by smaller providers allowed
them to form a network together that began to threaten even America’s
largest ISP.
Unfortunately we never quite reached that point with instant messaging.
However that hasn’t stopped many of us from continuing to strive for a
similar outcome even as our symbol of hope, the open email network, is
under threat today more than ever before.
Despite numerous projects, communities and organizations campaigning for
decades in favour of open messaging systems, the space is still
dominated by large silos. The largest the world has ever known. WhatsApp
alone has over 2 billion users. That means a significant portion of
the world’s communications are flowing through a single company. A
company that has a simple business model - amassing data about people
and leveraging that data to help their actual customers (other
businesses) influence the beliefs, biases and behaviour of the users of
their platforms.
The slippery slope
Despite the dizzying numbers associated with WhatsApp today, it had more
humble beginnings. Founded by two ex-Yahoo employees, Brian Acton and
Jan Koum, it began as a simple messaging app for iPhones. The server was
originally based on an open-source XMPP server, and
used the XMPP protocol. However the goal of WhatsApp was not openness
and federation, and they soon diverged far from standard XMPP.
As WhatsApp grew, early users may recall that they also began charging a
small fee for accounts ($1/year). Their reasoning was simple:
“Remember, when advertising is involved you the user
are the product.
Your data isn't even in the picture. We are simply not interested in any of it.
When people ask us why we charge for WhatsApp,
we say ‘Have you considered the alternative?’“
Nevertheless, just two years later it was announced that WhatsApp had
been acquired by the internet’s fastest-growing advertising platform,
Facebook.
Despite declaring to the EU competition commission that linking an
individual’s data between WhatsApp and Facebook was not technically
feasible this is exactly what they went on to do, leading to a €94
million fine. Little by little, Facebook has been
loosening their privacy policies to allow them to absorb WhatsApp data
into their daily operations.
So when, in early 2021, the latest update to the privacy policy gave users
of the platform a clear ultimatum to allow this sharing or close their
account, many users wisely began to seek alternatives. Finally, the
moment we had been waiting for had arrived.
Many of us advocates of open communications seized the opportunity, and
recommendations were soon flying around for the wide range of alternative
messaging systems we’ve been building these past years. “Use XMPP!”,
“Use Matrix!”, “Use Signal!”, to name a few.
Despite a marked increase of signups on XMPP and Matrix servers, of
these three it was Signal that won by far the largest share of new users.
Millions of people flocked from WhatsApp and overloaded Signal’s servers,
resulting in disrupted message delivery across Signal’s service for days.
This service disruption was possible because, unlike XMPP and Matrix,
Signal is centralized, and all messages flow through a single set of
servers, the same model as WhatsApp.
XMPP and Matrix are both federated networks. Rather than a single entity
controlling the network, there are many servers to choose from, run by
many different independent providers. Even with a server down,
overloaded or closed to new users, the rest of the network continues
functioning.
So why did Signal receive millions of users, and XMPP/Matrix did not?
Signal
At this point it’s impossible not to reference The Ecosystem is Moving,
a 2016 blog post by Signal’s founder and CEO, Moxie Marlinspike. In this
post Moxie details all the problems he sees with protocols becoming
open internet standards. In particular, that they lose their ability to
evolve, and that evolution is vital to compete in our industry’s “moving
ecosystem”.
We got to HTTP version 1.1 in 1997, and have been stuck there
until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly
frozen in time circa the late 1990s.
Mobile optimizations (bandwidth, connectivity, push notifications)
Full cross-device message synchronization
Many of these things didn’t even exist as concepts back when XMPP began.
Adding them was only possible due to XMPP’s smart design: a core
protocol, with a suite of extensions (known as XEPs). New
extensions are added as needed, and irrelevant ones get deprecated.
To help keep everyone on the same page as the protocol evolves, the XMPP
Standards Foundation (XSF) annually publishes the recommended XEPs that
different classes of software (e.g. instant messaging,
social networking, or smart devices) should be
implementing. These round-ups are known as compliance suites.
The documentation site Modern XMPP also serves as a useful reference
guide for modern XMPP implementations (including UI/UX considerations,
which are not covered by the protocol-level documentation).
The unfortunate truth
The effort required in advancing the protocol is significant. And that’s
not even counting the implementation work. XMPP has a diverse and open
ecosystem. There is no single “XMPP client”, instead the ecosystem is
composed of… just about anyone who decides to write XMPP software. The
vast majority of this software is free/open-source, and developed by
volunteers and communities.
Publishing protocol updates does not magically mean the changes are
implemented in all XMPP software overnight. Some projects are more active
than others, and each contributor is an individual with their own life
and work schedule. Unfortunately this means that it’s very difficult to
evolve the protocol and keep everyone 100% in sync. Luckily XMPP’s
modular design makes it easy for some software to advance ahead of others
without having to lose backwards compatibility with the rest of the
network. If we didn’t have this feature, we would always be in a state where
half of the network is unable to communicate with the other half of the
network, or more likely we would be stuck with the initial set of
features because nobody would want to be the first ones to become
incompatible with everyone else.
But Moxie is right. We could move much faster if we didn’t care about
interoperability, software diversity, and decentralization.
And that is the approach Signal is taking.
Product or protocol?
It’s clear that there are trade-offs to be made here. Signal’s
product-led development excludes others from participating in the Signal
network. But it allows them to remain agile, and implement new features
as fast as they can write and ship code.
I put together some of the trade-offs into the following table:
Building an ecosystem
Building a product
Focus on protocol
Focus on implementation
Mostly documentation
Mostly code
Cross-project collaboration
Single project/team
Building for developers
Building for end-users
Slow evolution
Evolves as fast as you want
Achieve diversity
Achieve a monoculture
Robust
Single point of failure
I think that Signal’s approach is laudable for the number of people that
they have helped divert from data-mining platforms, and helping to remind
people that surveillance capitalism isn’t the only way to do things.
They’ve built a good user-friendly product, and they have done it with
security and privacy at its heart.
But we have to aspire to more than this. Signal is a centralized, closed
system. That means to communicate with your contacts who use Signal, you
must also consent to their terms, their software, their US jurisdiction.
You have to be okay with their servers being hosted with large cloud
providers such as Amazon and Google.
But one thing the past has shown us is that things change. Technologies
evolve, business leaders come and go, motives adjust. Signal today may
be as benign as WhatsApp before its acquisition by Facebook. But change
is inevitable, from whatever direction it comes. Signal is a technical,
organizational and political point of failure.
Best of both worlds
Thinking about the table I presented above. Consider that perhaps the
options on each row are just the extreme positions. Perhaps we can try
to strike a balance between them - making intelligent choices as we go.
What if we could make a Signal that was a little more open? And an
XMPP that was a little bit less diverse? Accept that we would trade some
of the agility for robustness, and some of our diversity in favour of
consistent usability.
Can we move beyond Signal’s flaws to build something that is open,
interoperable, user-friendly, consistent and decentralized? I believe
so, and as they say, there’s only one way to find out.
Snikket
Snikket is an initiative to bring a more product-led approach to the
XMPP ecosystem. It’s a project that will deliver a suite of XMPP
software: a single app for each platform, and an easy to deploy server
for self-hosting.
The goal is to reduce fragmentation in the XMPP ecosystem, and ensure that
people have access to a familiar brand across all platforms. This brand
will represent a consistent set of features, and no interoperability
issues. The software is all open-source, and of course still (the latest
and greatest) XMPP.
Hopefully Snikket will also become an easy gateway to the world of XMPP
for users who may previously have found it inaccessible due to the need
to understand the ecosystem and choose the best software for each platform.
All the other XMPP software continues to exist, and people are free to
use anything that better suits their needs.
Starting from scratch would be a massive undertaking, and would require
resources beyond the reach of an unfunded open-source project. Instead we
are building on top of the amazing work that is already being done in
XMPP implementations. For our Android client we selected Conversations.
For iOS, Siskin. The server is based on Prosody.
All of these projects are good projects on their own. But by combining
them under a single brand, performing focused interoperability testing
and improving UI/UX consistency, we gain a new project that is greater
than the sum of its components.
To be clear, these are not “hard forks” of the projects. Quite the
opposite. We work closely with the developers, and have sponsored
features in both Conversations and Siskin to get to where we are today.
Our work on invite-based onboarding grew into a whole new feature
in Prosody. Everything that makes sense in the upstream project gets
pushed upstream. Lessons learned in UI/UX will likewise get added to the
Modern XMPP documentation for other client developers to benefit from.
Snikket is not about replacing any of the individual projects, but
about joining them together in a neat way and extending XMPP’s reach to
new audiences.
Back to the future
Will Snikket alone turn the tide against proprietary communication
platforms? Maybe, maybe not. But we’re part of a growing movement that
agrees it’s time to stop repeating history, and finally
redecentralize the internet, the way it was intended.
Thanks to Kim Alvefur, Georg Lukas and Jonas Schäfer for their editorial
review during the writing of this post.
Want to help support the project? Donations are welcome!
All contributions will help us to continue work on the project and
accomplish the goals on our roadmap. Want to talk?
Join our community chat.
Five months have passed since the release of Gajim 1.2.2. Many new features have been developed during this time, including a complete redesign of both Gajim’s Preferences window and configuration backend, an all new Profile window, support for Chat Markers, a new user interface for voice/video calls, and much more.
What’s New
Preferences
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
Chat Markers
A long anticipated feature has finally found its way to Gajim: Chat Markers (XEP-0333). You already know the check mark which Gajim shows as soon as a message has been delivered (XEP-0184). Now, as soon as your contact reads your message, you’ll notice a double check mark replacing the single check mark, marking the message as ‘read’. This is of course on the condition that your contact’s chat client actually sends Chat Markers. Gajim lets you choose whether you want to send these markers via Account Settings > Privacy > Send Read Markers. As soon as you read a message on another device (e.g. your phone), Gajim will remove the now obsolete notification. By default, this works for 1:1 chats and private group chats (tested with Conversations and Dino).
Profile
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.
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.
Gajim's new Profile window: view mode
Gajim's new Profile window: edit mode
Gajim's new Profile window: picture selector
Group Chat Invitations
Receiving a group chat invitation can sometimes be ambiguous. ‘Do I really want to join this chat, or should I decline the invitation?’ In order for you to make an informed decision, Gajim now shows some information about the chat (group chat’s picture, name, and description) before joining. Furthermore, many people want to join public group chats using a different nickname from the one they use for private group chats. Gajim now offers to choose a nickname directly before joining.
The new Group Chat Invitation window
Audio & Video
Last but not least, there have been some improvements to Voice/Video calling. Gajim has had support for Voice/Video calls for quite some time, but the code has also been broken for a while now, because it is not actively maintained. We took some first steps (friendlier user interface, basic audio/video transmission), but these are highly experimental. Also, this feature is based on older standards, which makes it incompatible with Conversations for the time being (for example missing support for XEP-0320).
Plugin Updates
Gajim’s URL Image Preview is now able to preview audio files
The Syntax Highlighter plugin now features a ‘Paste as Code’/‘Paste as Code Block’ entry for the chat input
It is now possible to install the ‘Ayatana Appindicator integration’ plugin via Flatpak
More Changes
New
Setting for automatic history cleanup
Chat-specific ‘Group Chat Settings’ page
‘Mark as Read’ button for message notifications
‘Send Message’ button in chat windows
Support for vCard4 (XEP-0292)
Windows: support for XMPP link handling
Added a preview when pasting images from the clipboard
Changes
Gajim will use direct messages in non-anonymous group chats instead of PMs (this is configurable)
Message styling: removed _underline_ style and added ~strikethrough~ style, making Gajim standard compliant
Removed notification for contact sign in/out
Removed ‘Auto copy’ workaround for Ctrl+C usage in the chat window
If Gajim fails to join a group chat, it now offers a Retry button (and also ‘Forget Group Chat’)
Changed default: Pressing the Escape key will not close chat windows
Linux: Emoji button now opens GTK’s native Emoji chooser (with categories and recently used emojis)
Improved A/V codec selection
Fixed some regressions with non-english keyboard layouts
Fixed command for opening the Start Chat window (gajim --start-chat)
A/V menu entries are now updated (enabled/disabled) correctly when receiving the contact’s capabilities
Fixed GSSAPI support
Some shortcuts now use Primary (Ctrl/Cmd) instead of Alt (which is often used by Window Management): Change Subject (<Primary><Shift>S), Emoji Chooser (<Primary><Shift>M)
Fixed a bug where dropping selected text on a chat window would fail
Fixed ‘Show status changes’ setting being ignored for group chats
On Windows, we had to disable translations temporarily. This is due to a bug in a package Gajim relies on. Hopefully we’ll be able to ship the next version with translations again!
Zeroconf (serverless messaging) has not been re-implemented yet
Mac beta is ready and available for download. The iOS one will come soon to testflight. This matches what used to be the alphas. Going forward the hope is to have just these regular builds and possibly nightly alphas published here (depending on how the CI work goes)
Monal is growing! That means we need to improve the way we collaborate and manage the various projects that build the client and server stack that makes it tick. With that in mind the development team is migrating from a collection of personal accounts to an organization in GitHub. Monal related projects are now in the monal-Im organization . This shouldn’t break any existing links the source code, bug reports or tickets. Please let us know if you do encounter any issues.
The Ignite Realtime Community is pleased to announce the 4.6.2 release of Openfire. For SQL Server users, this release contains an important fix that prevented a database upgrade script from working. Otherwise, the changelog denotes three other issues resolved. One change to note is a subtle difference on the Openfire administration console with how the version is reported in the upper right corner. For example:
The git repository commit hash the build was based off of is included to provide a more definitive provenance of the version you are running. In this case, “b61bce3” refers to the merge commit for the 4.6.2 release.
Release artifacts can be found on our download page and they have the following sha1sum values
And for those curious, here is an accounting of the number of 4.6.1 downloads by artifact.
Artifact
Downloads
openfire-4.6.1-1.i686.rpm
182
openfire-4.6.1-1.noarch.rpm
429
openfire-4.6.1-1.x86_64.rpm
1148
openfire_4.6.1_all.deb
2501
openfire_4_6_1.dmg
292
openfire_4_6_1.exe
1548
openfire_4_6_1.tar.gz
888
openfire_4_6_1.zip
404
openfire_4_6_1_bundledJRE.exe
509
openfire_4_6_1_bundledJRE_x64.exe
2219
openfire_4_6_1_x64.exe
3611
openfire_src_4_6_1.tar.gz
126
openfire_src_4_6_1.zip
25
Please report any issues in the community forums or stop on by the online groupchat to let us know how things are going for you. Thanks for your interest in Openfire!
The Ignite Realtime community is happy to announce the release of version 0.8.0 of the Push Notification plugin for Openfire!
This update fixes a problem that prevented certain clients (like Siskin) from successfully register a push notification service.
Note that, after upgrading the plugin from an older version, Openfire will need to be restarted. This too is caused by a bug, that has been addressed in this new release (but one last restart is needed to remove remnants of the bug that was present in previous versions of the plugin).
As always, your installation of Openfire should automatically detect the availability of the update in the next few hours. Alternatively, visit the plugin archive page to download the plugin directly.
We don’t track the number of users Monal has. We do see thousands of downloads in the App Store statistics. Any user counting and crash tracking provided by Apple is strictly opt in only. So it always undercounts. However because ever user registers a push device with the push server we do see how many devices there are using Monal. This is a very rough estimate that is a bit inflated because you can reset your push deviceids. With all that said, there are currently 61,953 devices registered to receive push notifications. On January 31th the push sever sent 77,199 push notifications. Which comes to just under one a second.
There was a push outage for some users today for a few hours. Apple updated their intermediate certificate and it appears to have gone in effect earlier than expected. The new certificate expires in 2030 so this shouldn’t be an issue again. Apologies for the inconvenience.
A year ago, Snikket was first announced publicly, at the FOSDEM conference in Brussels.
FOSDEM 2021 is next week, online of course, and I’ll be giving a talk about some of the
thoughts that led to me starting the Snikket project.
Today that progress continues, as we release the largest update to our self-hosted server
software yet! This release includes a web administration dashboard, support for multiple distinct
groups of users, and finally… support for Raspberry Pi and other ARM devices.
Admin dashboard
Until now the only way to manage your Snikket server - for example to invite new users or reset
passwords - was by using the command-line. That is all about to change, as we now have a
lovely web interface to perform all kinds of management tasks!
The Snikket web interface
The dashboard is already translated into multiple languages (currently English, French, German,
Italian, Indonesian and Polish).
We also have a simple portal for non-administrative users to log in and manage their account.
Currently this contains a profile editor, and will grow to include other account settings, and
data import/export.
The user profile editor
This project has been the work of Jonas Schäfer, without whom it wouldn’t have been possible to
ship anything quite as extensive or polished by now! Many thanks also to the community members
who have contributed the initial translations.
Raspberry Pi and ARM support
We have grown our build infrastructure to include two Raspberry Pi servers, which now provide
continous builds for ARM (32-bit and 64-bit) architectures. This means that finally the Snikket
Docker images work out of the box on just about any Raspberry Pi device.
Due to the relatively low resource requirements of the Snikket server, and the relative affordability
of Raspberry Pi devices, they make a great device to begin your self-hosting journey!
Circles
Snikket is designed with small groups of people in mind. Whether your Snikket instance is serving
your family, club or workplace, we chose to make contact discovery easier by automatically showing
all other users on the same Snikket service in your contact list.
However this could be problematic if you wanted to share the same server across multiple social
groups. Maybe you want to invite your gaming buddies to your Snikket server, but without them
awkwardly finding all your family members in their contact list.
We have added a new feature which allows you to have multiple groups of people, which we refer to
as “circles”. When you create an invitation you can choose which circle to assign the new user(s)
to.
If you are upgrading from a previous version of the Snikket server, there will be an initial
migration process that automatically moves all users to a new default circle.
Finally, circles have an associated private group chat to which all circle members are invited.
This replaces the clunky ‘general’ chat that was created in previous releases.
Other changes
We’ve made some architectural changes in this release. If you’re upgrading from a previous release,
make sure you follow the upgrade notes in the changelog.
The file upload limit is now 16MB (the same as WhatsApp’s limit). We are working on allowing
even higher limits but with per-user quotas for a future release, to ensure you don’t run out of
precious disk space :)
Finally, if you’re setting up Snikket for the first time, we now have a collection of scripts and
resources to help you get started, over at snikket-selfhosted!
We’re looking forward to hearing feedback about this release. Let us hear your success
stories 😉
A quick reminder that this is an independent open-source project working to provide a free (as in
freedom) alternative to proprietary mainstream messaging services. If you benefit from the software
we produce, or simply want to support our work, feel free to donate, no matter how small!
This release enables the users to send files via drag and drop. Furthermore, it
is possible to see which chat client and operating system a contact is using.
Additionally, newlines can be inserted into a text message with ShiftEnter now.
We are working on some major features such as message history synchronization
(MAM) and typing notifications. They are nearly finished and we hope to ship
them in Kaidan 0.8 very soon™.
Drag’n’drop for files
Changelog
These are the new features of the release:
Display client information (name, version, OS) of contacts (jbb, lnj)
Drag’n’drop for sending files (jbb)
Allow pasting images from the clipboard (Ctrl+Shift+V) into the chat (jbb)
Allow inserting newlines using Shift+Enter (jbb)
Add configuration of custom hostname/port (jbb, melvo)
Favourite emojis are shown by default now (melvo)
Search emojis by “:" (melvo)
Display connection errors in the global drawer after login (melvo)
Improved design of media preview sheets (jbb)
Restructure message sending bar (melvo)
And the following bugs have been fixed:
Do not interpret random URLs as files anymore (lnj)
Fix the style of buttons when using Material style (melvo)
Fix file dialog and media drawer opening in some cases (melvo)
Fix opening of the login page when scanning QR code without password (melvo)
We urge you to update to Monal ≥ 4.9 if you haven’t done it yet.
We discovered a security bug in Monal < 4.9 dubbed CVE-2020-26547:
Monal before 4.9 does not implement proper sender verification on MAM and Message Carbon (XEP-0280) results. This allows a remote attacker (able to send stanzas to a victim) to inject arbitrary messages into the local history, with full control over the sender and receiver displayed to the victim.
we were asked to post an update of our development journey for the next xmpp summit. Because we as the developers of the monal beta are way too proud of our own achievements, we ask you as the community to provide a more realistic view of the monal project.
Can you write a (really) short paragraph about where the project started when you first used it, where it is now (if you are still using it ;)) and what improved or not improved over the past year. What are the things you are most happy with? What upcoming things do you await most eagerly?
Please submit your user stories as blog comment or in the monal groupchat until 2021-02-03 (YYYY-MM-DD).
If you want, just add your name below the text and we’ll publish it along the text (or leave it out to get published anonymously).
Thank you very much for the last year full of debugging builds with us! Anu, Emus, Friedrich, Jim, Thilo
This is the French translation of the original blog post.Cet article est la traduction française de l'article original du blog.Thanks to anubis, mathieui, nÿco, pmaziere, pulkomandy and ysabeau for their translation and review!
Parce qu’elles ne comprennent pas les critères à prendre en compte pour le choix d’un type de messagerie instantanée, plusieurs
personnes m’ont récemment contacté pour me demander lequel ils devraient utiliser et si elles devraient migrer d’une des solutions
ayant pignon sur rue à une autre du même acabit. Je me suis demandé comment répondre à ces questions. Évidemment, j’aurais simplement
pu plaider pour XMPP (Extensible Messaging and Presence Protocol), mais j’ai pensé que cela ne serait peut-être pas une réponse
utile en soi. Souvent, les gens prennent une décision rapide concernant leur logiciel de communication, et ce n’est généralement pas
un choix bien réfléchi, ce qui, plus tard, les amènera inexorablement à passer à une autre messagerie instantanée.
Beaucoup ne feront en fait qu’ajouter une autre messagerie instantanée à leur collection toujours croissante de messageries, ce qui
est probablement plus frustrant qu’utile. Cela me ramène à la question initiale : quel enjeu et quel problème veut-on résoudre ici ?
Quelles sont leurs motivations ? Peut-on trouver une solution avec un meilleur fondement technologique qui évite l’effet de mode et
n’implique pas l’installation de plusieurs applications de messagerie ?
Il y a autant de réponses que de personnes qui posent ces questions : quand certains ont besoin d’une réelle protection de leurs
données personnelles, les autres demandent un contrôle complet sur celles-ci, ou s’attendent simplement à pouvoir joindre tous leurs
contacts à partir du même appareil. Quelles que soient ces attentes, migrer d’un système de messagerie à un autre implique souvent de
laisser certains contacts derrière soi. De nombreux systèmes de messagerie ont en plus fait le choix de réclamer un numéro de téléphone,
ce qui n’est pas un bon point de départ pour la protection des données personnelles.
Maîtrise de vos communications
Comme vous vous en doutiez, je vais recommander XMPP. Je pense que la première chose à faire n’est pas de choisir une application de
messagerie, mais de choisir la technologie logicielle sous-jacente. Réfléchissons d’abord à la technologie avant de sauter d’une
recommandation à l’autre.
XMPP est un protocole ouvert, comme HTTP pour le web. L’apparence de votre site web n’a pas d’importance, tout le monde peut interagir avec.
L’idée derrière XMPP, c’est d’appliquer le même principe à la messagerie instantanée.
La XSF, ainsi que beaucoup de personnes impliquées dans cette technologie libre, pense que XMPP est un excellent choix d’un point de vue
technique, et pas seulement en ce qui concerne la protection des données personnelles. XMPP existe depuis plus de 20 ans, ce qui a permis
d’accumuler beaucoup d’expérience de terrain. Cela inclut de nombreux indicateurs clés pour le choix d’une technologie de communication
maitrisée, puisqu’il prend en charge :
la décentralisation des services de communication (fédération) ;
la standardisation et l’extensibilité de la technologie ;
l’interopérabilité ;
l’innovation par la mise en place d’un développement ouvert ;
la protection et le contrôle des données personnelles, incluant le chiffrement de bout en bout.
XMPP fournit les éléments d’information permettant de gérer la communication dans un réseau. Mais chaque personne décide du logiciel
client qui lui convient, et sur quel serveur ses données doivent être stockées.
Contrairement à la situation actuelle, où d’autres gens vous incitent à utiliser leur application préférée, dans l’univers d’XMPP vous
avez le choix entre de nombreux clients de messagerie : choisissez celui qui vous plaît aujourd’hui, indépendamment des effets de mode,
quitte à en changer plus tard. À la différence d’autres technologies de communication, peu importe l’application que vous utilisez ou le
serveur qui héberge vos données, vous resterez toujours sur le même réseau que vos contacts. Je pense que c’est une vraie solution.
Ce n’est pas une question d’applications, mais de technologie
Décidez-vous sur la technologie que vous prévoyez d’utiliser, et sélectionnez ensuite quel logiciel correspond à votre usage ou à votre
environnement. XMPP et sa communauté ont accumulé une grande variété d’expérimentations qui ont été mises en pratique dans un grand nombre
de logiciels. Nous pensons que c’est une bonne solution pour la plupart des individus et des organisations, ainsi que pour la cohérence
d’Internet comme un tout, sans compter qu’elle reste ouverte à de futures innovations sans en limiter l’origine.
En plus d’un large choix de logiciels de messagerie, XMPP propose également plusieurs serveurs et outils de développement pour construire
vos propres infrastructures.
Il n’y a pas qu’une seule manière de concevoir des applications de communication. Faites le choix d’une technologie standardisée qui restera
valable à long terme : pour cette raison, et pour beaucoup d’autres, nous recommandons l’utilisation d’XMPP!
Si vous avez l’intention de choisir une solution pour la prochaine décennie, laissez-moi vous orienter vers plus de documentations :
Pour commencer, mettez le pied à l’étrier avec le site de XSF [en anglais] ;
Un article du blog de la XSF : It's all about choices and control (C’est une question de choix et de contrôle) [en anglais] par Laura, écrit et 2015 ;
Modern XMPP, un site web en anglais utile aux développeurs comme aux nouveaux arrivants pour se lancer dans XMPP ;
This is the Romanian translation of the original blog post.Aceasta este traducerea în limba română a postării originale de pe blog. Thanks for reviewing Licaon_Kter!
Mai multe persoane m-au contactat recent întrebându-mă ce fel de aplicație de mesagerie ar trebui să folosească acum - au spus că de fapt nu înțeleg despre ce ar trebui să fie preocupați și dacă ar trebui să treacă de la una dintre cele cunoscute la alta.
M-am gândit cum să răspund. Evident, aș fi putut pleda pur și simplu pentru XMPP (Extensible Messaging and Presence = Protocolul Extensibil de Mesagerie și Prezență), dar apoi m-am gândit că acest lucru ar putea să nu fie un răspuns util în sine. Adesea, oamenii iau o decizie rapidă cu privire la programele lor de comunicare și de obicei aceasta nu este o alegere întemeiată; și astfel vor ajunge să treacă la o altă mesagerie mai târziu.
Mulți vor adăuga de fapt o altă aplicație de mesagerie la colecția lor tot mai mare, ceea ce este probabil mai mult frustrant decât util. Acest lucru mă aduce înapoi la întrebarea inițială: Ce problemă se dorește a se rezolva? Care sunt stimulentele? Se poate găsi o soluție cu o bază tehnologică mai bună care să evite exacerbările mediatice și nu implică instalarea mai multor sisteme de mesagerie?
Diferite persoane au considerații diferite pentru a răspunde la această întrebare - unele necesită confidențialitatea efectivă a datelor sau suveranitatea datelor sau pur și simplu abilitatea de a avea acces la toate contactele lor dintr-un singur loc. Cu toate acestea, trecerea de la un sistem de mesagerie la altul va însemna adesea lăsarea în urmă a unor contacte. Multe sisteme de mesagerie necesită, de asemenea, un număr de telefon, ceea ce nu este ceva grozav pentru intimitate.
Suveranitatea comunicării
După cum ați suspectat deja, voi pleda pentru XMPP. Cred că prima alegere pe care ar trebui să o facem nu este ce aplicație de mesagerie să folosim, ci ce tehnologie e la baza ei. Luați în considerare mai întâi alegerea tehnologiei, înainte de a trece de la o recomandare la alta.
XMPP este un protocol deschis, la fel ca HTTP pentru Internet. Nu contează cum arată site-ul dumneavoastră, toată lumea poate interacționa cu acesta. Acest principiu este ideea din spatele XMPP, dar pentru mesagerie instantanee.
La XMPP Standards Foundation și împreună cu mulți alții implicați în această tehnologie deschisă, credem că XMPP este o alegere excelentă ca tehnologie de comunicare, nu doar în ceea ce privește confidențialitatea datelor. XMPP există de peste douăzeci de ani și multă experiență practică a fost adunată în tot acest timp. Aceasta include mulți indicatori cheie pentru alegerea tehnologiei și care permite suveranitatea comunicării, deoarece susține:
Descentralizarea serviciilor de comunicații (federație)
Standardizarea și extensibilitatea tehnologiei
Interoperabilitate
Inovația și utilizarea dezvoltării deschise
Confidențialitatea și controlul, de asemenea, prin utilizarea criptării de la un capăt la altul
XMPP oferă informații bine definite despre cum să fie gestionată comunicarea într-o rețea. Utilizatorul decide ce program de mesagerie i se potrivește sau unde ar trebui stocate datele.
Spre deosebire de situația actuală în care alte persoane vă sugerează să utilizați aplicația sistemului lor preferat, în universul XMPP aveți libertatea de a vă alege aplicația de mesagerie dintre multe opțiuni - alegeți-o pe cea care vă place, nu cea aleasă de ceilalți ca moftul zilei citit pe Internet. Diferența este că, indiferent de aplicația dumneavoastră de mesagerie sau de cea a prietenilor voștrii, aveți în continuare confortul de a vă afla în aceeași rețea cu toate contactele voastre, indiferent de alegerea de astăzi. Cred că aceasta este o soluție reală.
Nu este vorba despre aplicație, ci despre tehnologie
În decizie luați în considerare tehnologia pe care intenționați să o utilizați, și apoi decideți ce aplicație de mesagerie vi se potrivește dumneavoastră sau mediului vostru. XMPP și comunitatea sa au acumulat o experiență variată, care a fost cu succes utilizată într-o mulțime de programe. Credem că aceasta este o soluție bună pentru majoritatea oamenilor și a organizațiilor de pretutindeni și pentru Internet în ansamblu - și este accesibilă pentru noi toți ca să inovăm în viitor.
XMPP are nu doar o gamă largă de aplicații de mesagerie; există, de asemenea, diverse programe pentru server și instrumentele (bibliotecile) pentru a vă construi singuri infrastructura.
Nu există un singur mod în care aplicațiile de comunicare trebuie să fie proiectate. Luați o decizie durabilă pentru o tehnologie standardizată - în acest scop, și multe altele, vă recomandăm utilizarea XMPP!
Dacă sunteți interesați să faceți o alegere pentru următorul deceniu, permiteți-mi să vă îndrum spre lectură suplimentară:
Recientemente, varias personas se han puesto en contacto conmigo para preguntarme qué tipo de mensajería instantánea deberían utilizar ahora; me han dicho que, en realidad, no entienden de qué deberían preocuparse y si deberían cambiar de uno de los proveedores de mensajería instantánea comúnmente conocidos a otro.
Me pregunté cómo responder a esto. Obviamente, podría haber defendido simplemente el XMPP (Extensible Messaging and Presence Protocol), pero entonces pensé que esto podría no ser una respuesta útil por sí misma. A menudo, la gente toma una decisión rápida sobre su software de comunicación y ésta no suele ser una elección bien fundamentada, por lo que acabará cambiando a otro proveedor más adelante.
De hecho, muchos añadirán otra aplicación de mensajería instantánea a su creciente colección de aplicaciones, lo que probablemente sea más frustrante que útil. Esto me lleva de nuevo a la pregunta original: ¿Qué pregunta o qué problema se quiere resolver aquí? ¿Cuáles son los incentivos? ¿Se puede encontrar una solución con una mejor base tecnológica que evite el bombardeo y no implique la instalación de múltiples aplicaciones de mensajería?
Cada persona tiene sus propias consideraciones para responder a esta pregunta: algunos requieren una privacidad efectiva de los datos, o la soberanía de los mismos, o simplemente la posibilidad de llegar a todos sus contactos desde un solo lugar. Sin embargo, pasar de un sistema de mensajería a otro suele significar dejar atrás algunos contactos. Muchos sistemas de mensajería instantánea también requieren un número de teléfono, lo que no es bueno para la privacidad.
Soberanía de la comunicación
Como habrás sospechado, abogaré por el XMPP. Creo que la primera elección que hay que hacer no es la aplicación de mensajería a utilizar, sino qué tecnología de software subyacente. Considera primero la elección de la tecnología, antes de saltar de una recomendación a otra.
XMPP es un protocolo abierto, como HTTP lo es para la web. No importa el aspecto de su sitio web, todo el mundo puede interactuar con él. Este principio es la idea detrás de XMPP, pero para la mensajería instantánea.
En la Fundación de Estándares XMPP, y con muchos otros implicados en esta tecnología abierta, pensamos que XMPP es una gran elección como tecnología de comunicación, no sólo en lo que respecta a la privacidad de los datos. XMPP existe desde hace más de veinte años, y en ese tiempo se ha acumulado mucha experiencia práctica. Esto incluye muchos indicadores clave para la elección de la tecnología y la habilitación de la soberanía de la comunicación, ya que apoya
Descentralización de los servicios de comunicación (federación)
Estandarización y extensibilidad de la tecnología
Interoperabilidad
La innovación y el uso del desarrollo abierto
Privacidad y control, también mediante el uso de la encriptación de extremo a extremo
XMPP proporciona información definida sobre cómo manejar la comunicación en una red. El usuario decide qué software de mensajería le conviene o dónde deben almacenarse los datos.
A diferencia de la situación actual, en la que los demás te sugieren que utilices su aplicación preferida, en el universo XMPP tu puedes elegir libremente entre muchas aplicaciones de mensajería instantánea: escoge el que más te guste, no el que le guste a los demás hasta la próxima moda de Internet. La diferencia es que, independientemente de la aplicación de mensajería que utilices o de la que usen tus amigos, sigues teniendo la comodidad de estar en la misma red con todos tus contactos, independientemente de tu elección actual. Creo que esta es una solución real.
No se trata de la aplicación sino de la tecnología
Considera la posibilidad de tomar una decisión sobre la tecnología que pretendes utilizar y, a continuación, decide qué aplicación de mensajería instantánea te conviene a ti o a tu entorno. XMPP y su comunidad han acumulado una gran experiencia, que ha sido utilizada con éxito en una gran cantidad de software. Creemos que es una buena solución para la mayoría de las personas y organizaciones que existen, así como para Internet en general, y está abierto a que todos hagamos innovaciones para el futuro.
XMPP no sólo cuenta con una amplia gama de software de mensajería instantánea; también hay varios software de servidor y las herramientas (bibliotecas) para construir la infraestructura por ti mismo.
No hay una única manera de diseñar aplicaciones de comunicación. Decídete de forma sostenible por una tecnología estandarizada - para ese propósito, y muchos más, ¡recomendamos el uso de XMPP!
Si estás interesado en tomar una decisión para la próxima década, permíteme indicarte algunas lecturas adicionales:
This is the German translation of the original blog post.Dies ist die deutsche Übersetzung des ursprünglichen Blogeintrags.Vielen Dank für die Korrekturlesung Daniel Brötzmann, Martin und Paul Schaub!
Kürzlich haben sich mehrere Leute bei mir gemeldet und gefragt, welche Art von Messenger sie jetzt verwenden sollten - sie sagten, dass ihnen nicht klar sei, worauf sie achten sollten und ob sie von einem der allgemein bekannten Messenger zu einem anderen wechseln sollten.
Ich fragte mich, wie ich dies beantworten sollte. Natürlich hätte ich einfach für XMPP (Extensible Messaging and Presence Protocol) plädieren können, aber dann dachte ich, dass diese Antwort allein vielleicht nicht hilfreich sei. Bei der Wahl ihrer Kommunikationssoftware treffen Menschen oft sehr schnelle Entscheidungen, die selten gut überlegt und fundiert sind; und so werden sie wohl erneut zu einem anderen Messenger wechseln.
Viele fügen sogar einen weiteren Messenger zu ihrem stetig wachsenden Repertoir von Messengern hinzu, was wahrscheinlich eher frustrierend als hilfreich ist. Das bringt mich zurück zur ursprünglichen Fragestellung: Welches Problem will man hier lösen? Was sind die Absichten? Kann man eine Lösung mit einer besseren technologischen Basis finden,
die nicht bloß dem Hype hinterher rennt und bei der man nicht mehrere Messenger-Apps installieren muss?
Verschiedene Menschen haben unterschiedliche Überlegungen zur Beantwortung dieser Frage - manche benötigen einen effektiven Datenschutz, andere Datenhoheit oder einfach die Möglichkeit, alle ihre Kontakte von einem Ort aus zu erreichen. Der Wechsel von einem Messaging-System zu einem anderen bedeutet jedoch oft, einige Kontakte zurückzulassen. Viele Messaging-Systeme erfordern außerdem eine Telefonnummer, was für den Datenschutz kritisch zu betrachten ist.
Souveränität der Kommunikation
Wie vielleicht schon vermutet, werde ich für XMPP plädieren. Ich denke, die erste zu treffende Entscheidung sollte nicht sein, welchen Messenger man verwendet, sondern welche zugrundeliegende Software-Technologie. Man sollte zunächst der Wahl der Technologie betrachten, bevor man von einer Messenger-Empfehlung zur nächsten springt.
XMPP ist ein offenes Protokoll, so wie es HTTP für das Web ist. Es spielt keine Rolle, wie die Webseite aussieht, dank des HTTP Protokolls kann man beliebige Browser wählen um mit ihr zu interagieren. Dieses Prinzip ist auch die Idee hinter XMPP, allerdings für Instant Messaging.
Bei der XMPP Standards Foundation und bei vielen anderen, die an dieser offenen Technologie beteiligt sind, sind wir der Meinung, dass XMPP als Kommunikationstechnologie gute Wahl ist, und das nicht nur in Hinblick auf Datenschutz. XMPP gibt es seit über zwanzig Jahren und in dieser Zeit wurde eine Menge praktischer Erfahrung gesammelt. Dazu gehören viele Kriterien und Indikatoren, die sich als wertvoll für eine fundierte Wahl der Technologie und Ermöglichung von digitaler Souveränität herauskristalisiert haben. Dazu gehören:
Dezentralisierung von Kommunikationsdiensten (Föderation)
Standardisierung und Erweiterbarkeit der Technologie
Interoperabilität
Innovation und der Einsatz offener Entwicklung
Privatsphäre und Kontrolle, auch durch den Einsatz von Ende-zu-Ende-Verschlüsselung
XMPP stellt definierte Informationen zur Verfügung, wie die Kommunikation in einem Netzwerk abgewickelt werden soll. Der Anwender entscheidet, welche Software er nutzen möchte und wo die Daten gespeichert werden sollen.
Im Gegensatz zur aktuellen Situation, in der andere einem ihren bevorzugten Messenger vorschlagen, hat man im XMPP-Universum die freie Wahl aus vielen Messengern. Jeder kann den Messenger wählen der ihm gefällt, nicht den, den andere mögen und der bei der nächsten Internet-Modeerscheinung wieder ausgetauscht wird. Der Unterschied ist, dass man unabhängig davon, welche Messaging-App man verwendet oder welche App die Freunde benutzen, immer noch den Komfort haben, mit all seinen Kontakten im selben Netzwerk zu sein, unabhängig von der heutigen Wahl. Ich denke, das ist eine echte Lösung.
Es geht nicht um die App, sondern um die Technologie
Man überlegt sich, welche Technologie man einsetzen will, und entscheidet dann, welcher Messenger zu einem selbst oder seiner Umgebung passt. XMPP und seine Community kann auf eine große Menge Erfahrungen zurückgreifen, die erfolgreich in einer Vielzahl von Anwendungen umgesetzt werden. Wir sind der Meinung, dass dies eine gute Lösung für die meisten Menschen und Organisationen da draußen sowie das Internet als Ganzes sein kann - und es ist offen für uns alle, um Innovationen für die Zukunft zu ermöglichen.
XMPP hat nicht nur eine breite Palette an Messaging-Software, es gibt auch verschiedene Server-Software und Werkzeuge (Bibliotheken), um die Infrastruktur selbst aufzubauen.
Es gibt nicht die eine Art, wie Kommunikations-Apps gestaltet werden müssen. Man kann sich nachhaltig für eine standardisierte Technologie entscheiden - dafür und für viele andere Zwecke empfehlen wir den Einsatz von XMPP!
Wenn der Text Interesse geweckt hat, eine Entscheidung für das nächste Jahrzehnt zu treffen, möchte ich auf diese weiterführende Lektüre hinweisen:
Gajim 1.3.0 is almost there and Gajim’s XMPP library python-nbxmpp had its 2.0.0 release! This month brings many bugfixes and a long anticipated feature: direct chat messages for private group chats.
Changes in Gajim
The first month of 2021 was mostly about bug fixing in preparation of the upcoming 1.3.0 release. Also, Gajim joined Fosstodon this month! 🎉
Gajim will now use direct messages in non-anonymous group chats instead of Private Messages (which would be routed through the group chat). This behavior is of course configurable, but the new default will reduce confusion significantly: If you start a chat with a group chat participant of a private group chat, Gajim will open a chat addressed directly to the participant.
What else happened
Added new debug mode: start gajim with --gdebug to see GLib debug messages
Bugfixes for the new profile window
Fixed race condition while removing an account #10401
Fixed issue with clipboard being cleared accidentally after pressing Alt+Tab
Bugfix for an error which occurred when closing the chat window while being in a call
Bugfix for tooltip error occurring with empty PEP info #10235
Plugin updates
Gajim’s Client Icons plugin enables you to see which chat client(s) your contact is using, by displaying the client’s name and icon. This month, blabber.im (a popular Conversations fork) has been added, and detection for both Movim and PSI+ has been improved.
Changes in python-nbxmpp
python-nbxmpp 2.0.0 has been released, featuring JID Escaping (XEP-0106), VCard4 (XEP-0292), and GSSAPI (XEP-0233) support. As covered in previous posts, module calls are now based on Python Generators. Furthermore, the module API has been simplified and harmonized.
We like to support things as long as we can. However, eventually we do see the need to drop older os support so we can focus efforts on current versions. The long life of Apple devices means we end up supporting very old hardware for a long time. For example, we still support the iPad mini 2 from 2013 running ios12. Thankfully apple also provides OS updates for a long time and everyone upgrades. There are actually a very small number of devices from 7-8 years ago that run iOS 12 but not 13 or 14. We are dropping support for these devices after the next release because ios12 is different enough that it needs a different push server and code and has increasingly required special debugging to deal with differences in the way the os works. It appears there are now only 24 ios12 devices actively using Monal. Apple stats are opt in only so there are definitely more but this number will still be much much smaller than the thousands more using iOS 13 and 14.
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.
