Snikket Blog on Snikket Chat

Snikket Server - September 2024 release

team@snikket.org (Snikket Team) — Wed, 11 Sep 2024 00:00:00 +0000

We hope you’ve been having a good summer (at least if you’re up here in the northern hemisphere). Today we’re back with a new release of the self-hosted Snikket server software.

This software is what’s at the core of the Snikket project - a self-hostable “personal messaging server in a box”. If you wish for something like Messenger, WhatsApp or Signal, but not using their servers, Snikket is for you. Once deployed, you can create invitation links for family, friends, colleagues… any kind of social group is the main target audience for Snikket. The invitation links walk even the least-technical people safely through downloading the Snikket app and joining your private Snikket instance.

If you’re not a self-hoster, we also have a hosted version which lets you get your own instance started in just a few clicks.

What’s new

Some highlights of what changes this release brings:

Invitations

We’ve made a number of small but important improvements to the way invitations are created and managed.

For example, people often told us that after creating a few invitation links and sending them out, they would forget who each link was created for and why. Now Snikket allows you to attach a brief custom note to invitations, visible only to admins in the list of pending invitations, making it easy to see at a glance who has yet to accept their invitation.

: Example of the new invitation form, which allows adding an optional comment

Meanwhile we’ve added an important feature that was missing from invitations - you can now specify the role that will be applied to anyone who joins using a given invitation link. Previously, if you wanted to set up e.g. a child with a “limited” account, they would first join as a normal user, and then you would need to navigate to the user management page and assign them the “Limited” role. With this new release, you are able to assign the role directly when you create the invitation, which is much simpler and more secure.

: Invitations now allow selecting the user’s role before they sign up

A really handy feature we’ve added is the ability to share the invitation link directly through other apps, if your web browser supports it (which most mobile browsers do). This can make it much easier to send invitation links via SMS/email or other apps in a couple of taps, without manual copy and pasting.

: An example of the invitation sharing feature in Firefox on Android

Changes to blocking

Though uncommonly used on private servers, it’s nevertheless possible to block people in Snikket. When you do this, the blocked person would receive a delivery error when attempting to send a message to someone who had blocked them. From this error, it’s possible to deduce that you have been blocked.

Based on feedback, we have adjusted this so that no delivery error is sent to people you have blocked.

Technical stuff

We’ve added a few new things that are not present in the interface, but are of interest to people deploying Snikket.

It is now possible to adjust the port of the STUN/TURN server. By default this adjusts the port of the internal server that is provided with Snikket, but if you have configured an external TURN server then it means you are now able to host that on non-standard ports too.

Self-hosted instances are now able to use International Domain Names (IDNs), i.e. domain names that contain unicode characters. This feature is not yet available for instances hosted by Snikket, but let us know if you’re interested.

Other

Of course these are just the highlights. We’ve also improved a bunch of things under the hood, either in Snikket or as part of Prosody, the open-source project which powers Snikket’s chat connections, and has been updated in this new release.

For more information, and more changes in this release, check out the release notes.

Upgrading

Upgrading an existing installation is super simple and takes less than a minute! You can find instructions in the ‘Upgrading’ section of the release notes.

If you have any questions or feedback about the new release, come and join the discussion in our community chat.

We hope you enjoy Snikket. Happy chatting!

Snikket Server - July 2024 release

team@snikket.org (Snikket Team) — Thu, 18 Jul 2024 00:00:00 +0000

We’re happy to introduce the July 2024 Snikket Server release.

This is the core software of the Snikket project - a self-hostable “personal messaging server in a box”. If you wish for something like Messenger, WhatsApp or Signal, but not using their servers, Snikket is for you. Once deployed, you can create invitation links for family, friends, colleagues… any kind of social group is a good fit for Snikket. The invitation links walk people through downloading the Snikket app and joining your private Snikket instance.

What’s new in this release?

Web portal

We’ve made some improvements to the admin dashboard, particularly around the management of invitations.

Role selection

Snikket supports roles, so that you can control who has access to admin functions, but also who you may want to restrict from accessing some functions (guests, kids, etc.).

Previously, all invited users would be assigned the default user role when they created their account. If you wanted the person to be an admin, or more importantly, a limited user, you would have to scramble to the dashboard to update their role after they registered.

Now you can select the desired role when you create the create the invitation:

Comments

Another piece of feedback we had, was that after creating a bunch of invitations, it was sometimes awkward to remember what a particular invitation was meant for. Now you can add a brief note to an invitation when you create it. This is for your information only, the invited user will not see what you write, but you and other admins can see it when you view the list of pending invitations.

After you have made your invitation, the next step is almost always to send it to the person you want to invite. Currently we have a feature to help you copy the link to your clipboard, so you can paste it into an email or text message, or whatever. But some platforms offer a built-in “share” functionality:

New setup guidance

We’ve added some hints to nudge people in the right direction when they might need it. For example, if you have no other users on the instance yet, we will show a link to the invitation section so people can get their friends, family and whoever on board.

Relatedly, we now show the number of active user accounts on the instance in the admin dashboard. This will be especially useful as we work towards features to (optionally) allow non-admins to invite people to an instance.

Privacy and security

A couple of tweaks in this release:

Snikket will no longer send a delivery error to someone you have blocked when they send you a message. This makes it harder for them to detect that you have blocked them (vs. just not reading their messages).

We also updated the security headers sent by our web dashboard, and removed the server version header from the web frontend. While not really a privacy/security issue in itself, it’s simply nobody else’s business!

For admins

We now support configuring the primary port used for STUN/TURN communication. This is sometimes necessary if you are using an external TURN service that uses a different port. Even if you are using Snikket’s built-in TURN server, it can be used to avoid port conflicts.

Snikket now supports deployment with International Domain Names (IDN). This means that domains containing certain special characters should now work, while previously some functionality was a bit buggy when using one of these domains. If you encounter any issues, please let us know! Also note that this only works for self-hosted installations right now, IDN is not yet supported by our hosting service.

The “announcement” functionality has been updated in this release. This is mostly invisible, though we plan to expand this functionality in the future. For now you will mostly benefit from the Snikket logo and the server name accompanying the update notification messages you receive, and when an admin sends announcements via the admin dashboard.

Obtaining certificates should be a bit more robust since this release (that is, going from something like 99% reliability to 99.9% reliability). We noticed that occasionally certain temporary errors from Let’s Encrypt were not handled very well. This mostly affects people setting up an instance for the first time.

Translations

Many thanks to people who added or updated the following languages for this release: Chinese (Simplified), French, Italian, Polish, Spanish, Swedish and Russian.

If your language is missing or in need of updates and you think you could help, let us know!

Everything else

We’ve made many other fixes and improvements in this release, many of them coming via our sister project Prosody. Thanks to everyone who contributed with code, testing, documentation and feedback ❤️

Snikket Android app temporarily unavailable in Google Play store [RESOLVED]

team@snikket.org (Snikket Team) — Sat, 13 Apr 2024 11:00:00 +0000

We initially shared this news on our social media page, thinking this was a temporary issue. But we’ve had no response from Google for several days, and want to explain the situation in more detail.

Update 16th April: Over a week after this began, Google have reinstated the Snikket app on the Play Store and everything works again. Thanks to everyone who gave us encouragement and support during this time! Feel free to read on for details of what happened.

Summary

We merged some changes from our upstream project, Conversations, and we submitted the new version to Google for review. Before responding, they removed the existing published version from the store. We have submitted a new version (on 10th April) that we believe should satisfy Google, but they have not yet published it or provided any feedback.

This means that it’s not currently possible for Android users to install the app using Google Play. We recommend that you install it via F-Droid instead.

Workaround for Android users

If you receive an invitation to Snikket, the Play Store link in the invitation will not work. The best course of action is to install the app using an open-source marketplace instead: F-Droid.

Follow the instructions on f-droid.org to download and install F-Droid.
Install Snikket using F-Droid.
After the Snikket app is installed, open your Snikket invitation link again.
Tap the ‘Open the app’ button.
Follow the Snikket app’s instructions to set up your new Snikket account.

The full story

I’m Matthew, founder of Snikket and lead developer. This is the story of how we arrived at this situation with Google.

It all began when…

A few months ago, Snikket, along with a number of other XMPP apps, found our updates rejected by Google’s review team, claiming that because we upload the address book entries of users to our servers, we need a “prominent disclosure” of this within the app. The problem is… we don’t upload the user’s address book anywhere!

The app requests permission to read the address book. Granting this permission is optional, and the reason is explained before the permission is requested. If you grant the permission, the app has a local-only (no upload!) feature that allows you to “link” your XMPP contacts with your phone address book contacts, allowing you to unify things like contact photos. Contact information from your address book is never uploaded.

Many messaging apps, such as WhatsApp, Signal, and others, request access to your address book so they can upload them to their servers and determine who else you know that is using their service. Google have decided that’s what we’re doing, and they won’t accept any evidence that we’re not.

We don’t have telemetry in our app, but we assumed that this feature is probably not used by most people, so we decided to remove it from the Play Store version of the app rather than continue fighting with Google.

Amusingly, Google also rejected the update that removed the ‘READ_CONTACTS’ permission. Multiple times. It took an appeal before they revealed that they were rejecting the new version it because one of the beta tracks still had an older version with the READ_CONTACTS permission. Weird.

I fixed that, and submitted again. They rejected it again. This time they said that they required a test login for the app. Funny, because we already provided one long ago. I assumed the old test account was no longer working, so I made them a new one and resubmitted the app. They rejected it again with the same reason - saying we had not provided valid test account credentials.

“You didn’t provide an active demo/guest account or a valid username and password which we need to access your app.” – Google reviewers

The weird thing was, when I logged in to that account to test it, I saw that they had logged in and even sent some messages. So they were lying?!

We submitted an appeal with all the evidence that the account was working, and their reviewers had even logged in and used it successfully. After some time, they eventually responded that they wanted a second test account. Why couldn’t they just say that in the first place?!

After adding credentials for a second account, and using the Snikket circles features to ensure they could find each other easily, we resubmitted.

Rejected again.

This time the rejection reason was really the best one so far: they claimed the app was unable to send or receive messages. Rather funny for a messaging app that thousands of people use to send and receive messages daily.

Wait, a messaging app that can’t send messages?

Once again, I logged into the test account we had provided to Google, and once again saw that they had successfully exchanged messages between their two test accounts. We submitted another appeal, with evidence.

Eventually they responded, clarifying that their complaint was specifically about the app when used with Android Auto, their smart car integration. I do not have such a car, and couldn’t find any contributor who had, but I found that Google provide an emulator that can run on a PC, so I set that up on my laptop and proceeded to test.

You won’t be surprised to learn at this point that the messaging functionality worked fine. We responded to the appeal, including a screencast I made of the messaging functionality working with Android Auto. They informed us that they were “unable to assist with the implementation” of their policies. Then at the end of their response, suggested that if we think the app is compliant, that we should resubmit it for review.

So we resubmitted the app, which by this point had already been rejected 7 times. We resubmitted it with no modification at all. We resubmitted the version they rejected. They emailed us later that day to say it was live.

How would I rate the developer experience of publishing an app with Google Play? An unsurprising 1 star out of 5. If I could give zero, I would.

The removal

But this was all a couple of months ago. Everything was fine. Until I merged some of the nice things Daniel has been working on recently in Conversations, the app upon which Snikket Android is based. We put the new version out for beta testing and everything was going fine - the app passed review, and a few weeks later with no major issues reported, we pushed the button to promote the new version from beta to live on the store.

On the 8th April we received an email from Google with the subject line:

“Action Required: Your app is not compliant with Google Play Policies (Snikket)”

I was ill this day, and barely working. For reasons that, if you have read this far, you will hopefully understand, I decided to take up this fight when I was feeling better. Confusingly, a couple of days later we received another email with the same subject. At this point I realised with horror that the first email was not about the new update - they had reviewed the current published version and decided to remove it entirely from the store.

With Snikket unavailable, anyone trying to add a new Android user to their Snikket instance (whether hosted or self-hosted) is going to have a hard time. This is not good.

Their complaint was that the privacy policy was not prominent enough within the app. They had previously hit Conversations with the same thing. Daniel had already put a link to the privacy policy in the main menu of that app and this was already in the update waiting for their review. They didn’t reject the update until a couple of days later, and for a different reason.

Unknown to me, Daniel had tried to re-add the ‘READ_CONTACTS’ permission to Conversations, hoping that with the new privacy policy link and other disclaimers in place, that would be enough. They had already rejected that, and he had removed the permission again. But he did this after I had already started testing the new beta release of Snikket. The order of events went something like this:

Daniel experimentally re-adds READ_CONTACTS permission to Conversations
I merge Conversations changes into Snikket, and begin beta testing
Conversations update gets rejected due to the permission, and Daniel reverts the READ_CONTACTS change
Without knowing of the Conversations rejection, I promote the Snikket beta to the store.
Google rejects the Snikket update

What’s interesting is that Google rejected only on the permission change. The contacts integration itself was still disabled in Snikket. This is strong evidence that Google just assumes that if you have the permission (and presumably network permission too) then of course you must be uploading the user’s contacts somewhere.

As soon as I realised the problem, I merged the new changes from Conversations and rushed a new upload to Google Play. However at the time of writing this, several days later, Snikket remains unavailable in the store and no feedback has been received from Google.

This is an unsustainable situation

During this period we have had multiple people sign up for hosted Snikket instances, and then cancel shortly after. This is almost certainly because a vital step of the onboarding process (installing the app) is currently broken. This is providing a bad experience for our users and customers, negatively affecting the project’s reputation and income.

We are grateful that alternatives such as F-Droid exist, and allow people access to open-source apps via a transparent process and without the tyranny of Google and their faceless unaccountable review team. We need to ensure these projects are supported, and continue to improve their functionality, usability and user awareness.

Finally, we also welcome the efforts that the EU has been working on with things like the Digital Markets Act, to help break up the control that Google’s (demonstrably) arbitrary review process has over the the success and failure of projects, and the livelihoods of app developers.

Google, are you there?

Security notice: Snikket not affected by CVE-2024-3094

team@snikket.org (Snikket Team) — Sat, 30 Mar 2024 09:00:00 +0000

A security vulnerability was intentionally added to a widely used open-source project known as ‘xz’. This project is packaged in many operating systems, and a lot of software depends upon it. The vulnerability has been assigned the identifier CVE-2024-3094.

Systems with the vulnerable package may allow an attacker to gain unauthorized access to the system via SSH, if your system’s SSH server was linked to the affected packages.

Thankfully, the vulnerability was discovered before it reached most operating systems. However if you are using a pre-release version of any Debian or Red Hat distribution, you may be affected and should install the available security updates and check for any signs of unauthorized access.

Snikket server

The Snikket server software builds upon Debian base images. We can confirm that Snikket uses the stable Debian release, and does not have the vulnerable packages.

Snikket Hosting

The Snikket Hosting platform is run on Debian servers. We also use the stable Debian release, and can confirm this vulnerability has not affected our service.

More information

Although the vulnerability does not affect Snikket itself, always ensure you install all available security updates for your host system to keep it secure.

Snikket Hosting is now available!

team@snikket.org (Snikket Team) — Thu, 21 Mar 2024 00:00:00 +0000

We originally launched the Snikket project because we believe that people need an alternative to centralized single-owner communication systems. Those platforms, including WhatsApp, Telegram, Messenger, require consent to undesirable terms and privacy policies. Even Signal, while cryptographically a marvel, is still subject to the control of a single organization and a single jurisdiction. Plus, most of these platforms are tied to your phone number, which makes them unusable or unsafe for some people.

We believe that the ideal online communication network is larger than any single organization, and that it should offer people freedom and choice. That’s why we built Snikket on open standards (XMPP) and everything we produce is open source, so that people can inspect it and run it themselves.

However, it became increasingly clear that, as easy as we make self-hosting, it’s always going to require skills or time that people don’t have. If we want everyone to be a part of this network, we can’t expect them all to learn Linux, SSH and system administration!

For some time now, we have been working on Snikket Hosting, a simple solution that enables anyone to get their own Snikket instance running for their family, friends, clubs, etc. with no technical knowledge and just a few clicks.

Thanks to the help and feedback from all our beta testers, we’re happy to announce that Snikket Hosting is now publicly available! 🚀

Our goal, as a not-for-profit organization, is to run this sustainably. Our business model is a simple one that does not involve data harvesting/mining. Instead we charge a simple fee per instance that you host with us (each instance can have multiple users). This fee pays for the servers, maintenance and other associated costs. Any extra revenue is used to further our goals - building and promoting sustainable communication solutions.

Snikket will continue to be available for self-hosting, as always. Today’s launch is about providing new ways to get started with Snikket, not replacing the options that are already available. If you are already self-hosting Snikket, or planning to, nothing is changing for you. Though please do donate to support the project, even a little helps!

🪙 Pricing

The current cost for a hosted instance is roughly $6 USD or €5.50 EUR per month, however the exact price may vary depending on your currency, region and how you pay - to take into account taxes, fees and the affordability in different regions.

This last point was a concern that several people raised with us during the beta period. After currency conversion, the average income between countries can still vary dramatically, sometimes up to 2x or more. This puts people from some regions at a disadvantage when purchasing many online services that focus only on people in the US or Europe. We believe in a global communication network, so we hope that factoring this into our price calculation will help to bridge that divide.

All our plans include a 14-day trial period, so you can see what you’re getting before we take any payment.

🦸 Beta users

As we promised when adding you to the beta, all beta users will be able to continue using the service for free for a period of time. We will roll out pricing for beta users in the coming months, including a special offer in recognition of your support! You will have at least 2 months of notice before we require you to upgrade to a paid plan. We will email you with details when it’s ready.

☎️ JMP partnership

Our partnership with JMP.chat continues! Every active JMP subscription is entitled to a free Snikket instance, which is a great complement to their service when SMS is not enough (unlike SMS, Snikket supports things like end-to-end encryption and video calling).

If you are currently using a hosted Snikket instance that JMP provided to you, nothing will change for you.

However, if you signed up directly with Snikket during the beta period (via my.snikket.org), then you are not currently included in JMP’s special offer. You can either choose to pay for your instance when the time comes (see ‘Beta users’ above), or we can move your instance to JMP’s management. If you choose the latter, your instance will be managed by JMP and you will no longer have access to it via the Snikket Hosting dashboard. Access to your instance’s web portal will not be affected either way.

💬 Support and feedback

While we are no longer in beta, this is still new ground for us. If you encounter any problems or simply have questions, feel free to contact us at hosting@snikket.org and we’ll do our best to help.

❤️ Thanks

We want to thank all of our community, beta testers, sponsors and donors, including JMP.chat, for their support in enabling this launch. Thanks also to Neil from decoded.legal for assistance with many of the legal aspects of launching this kind of service.

😺 Curious to try out Snikket?

Snikket Server - January 2024 release

team@snikket.org (Snikket Team) — Wed, 10 Jan 2024 00:00:00 +0000

🎉 It’s here! We’re happy to introduce the January 2024 Snikket Server release.

What’s new in this release?

Changes to Circles

While Snikket is designed for groups of people to easily communicate with each other, we know that often people have multiple social groups. Our Circles feature allows the admin of the Snikket instance to decide which people will see each other within the Snikket apps, by grouping them into “circles”. For example, you could use this to separate your family from your friends, even within the same Snikket instance.

In previous releases, the Snikket server automatically created a group chat, and added everyone in the circle to that chat automatically. We received a lot of feedback that these chats were either not really used, or sometimes confusing (for example, because they are managed automatically by the server and you cannot manage them yourself within the Snikket app). Other people liked the group chats, but wished that more than one could be made!

In this new release, creating a circle will no longer create a group chat automatically. However you can also now create as many “circle chats” as you want, and give them individual names. This can be useful for creating per-topic chats for all members of a circle.

Of course if you just want normal private group chats, you can still create those within the Snikket app as usual, and manage the group yourself.

Last activity display

Sometimes people drop off Snikket, intentionally or unintentionally. For example, if they get a new phone and forget to reinstall the app or have problems connecting. In the web interface you can now see when the user was last active.

You can use this information to clean up unused accounts, or reach out to people who might need help regaining access to their account.

Connectivity and security

We have made a number of connectivity improvements. Snikket now enables IPv6 by default (previously it had to be enabled manually). If you don’t have IPv6, that’s fine… thanks to new changes we have made, Snikket will now adapt automatically to network conditions and connect using the best method that works. We expect IPv6-only networks to become increasingly common in the years ahead, so if your server is not currently set up for IPv6, consider doing that.

The new release now also supports DNSSEC and DANE 🔒, both of these are used to improve connection security. Currently these are disabled by default, however, because Snikket does not know if your system’s DNS resolver actually supports DNSSEC. We may enable it automatically in future releases if Snikket can determine that reliably. For now, it’s opt-in.

Faster and stronger authentication

We’ve also been working on optimizing and strengthening app-to-server authentication. A lot of this work was funded by NGI0+NLnet and is available in our sister project, Prosody. You can read more details in the blog post Bringing FASTer authentication to Prosody and XMPP.

Snikket already supported a neat security measure called “channel binding”, but it previously only worked over TLS 1.2 connections. TLS 1.3 usage has increased rapidly in recent years, and we now support channel binding on TLS 1.3 connections too. Channel binding prevents machine-in-the-middle attacks if the TLS certificate is compromised somehow.

All these features help protect against certain kinds of attack that were deemed unlikely until recently.

Dropping older security protocols

Mainly for compatibility reasons, Snikket previously supported an authentication mechanism where the client sends the user’s password to the server, but only over TLS-encrypted connections. This is how almost all website login forms work today, from your webmail to your online banking. However the Snikket apps actually use a more secure login method, which has many additional security features that you won’t find on most other online services.

Prioritizing security over compatibility, we have decided to disable less secure mechanisms entirely. If you use your Snikket account with third-party XMPP apps, bots or utilities that are not up to date with modern best practices, this may affect you.

Similarly, we have again reviewed and updated the TLS versions and ciphers that Snikket supports, in line with Mozilla’s recommendations, as we do in every release. This change also has the potential to affect connectivity from some very old apps and devices.

Easy account restoration

The Snikket apps, as well as many third-party apps, allow people to delete their Snikket account from within the app.

However, as the number of Snikket users has grown, so have reports from people who accidentally deleted their account! This can be due to confusion - e.g. intending to remove the account from the app, rather than removing it from the server. A number of these cases were due to confusing or buggy third-party apps. It doesn’t happen very often, but it was happening too often.

Of course, deleted accounts can be restored from backups (which you have, of course 😇) - but it was a complex time-consuming process to selectively restore a single account without rolling back everyone else’s data.

In this release, when a request is received from an app to delete a user’s account, the server will lock the account and schedule its deletion in 7 days (or whatever the server’s data retention time is set to). During this time, the account can be restored easily from the web interface if it turns out to have been a mistake.

Farewell to the welcome message

In previous releases, new accounts would receive an auto-generated “welcome message” from the server. This had a number of issues, and we have decided to remove it for now. Instead we will work on integrating any “welcome” functionality directly into the apps.

Languages and translations

Many languages received updates in this release, including French, German, Indonesian, Polish, Italian and Swedish.

We added support for two additional languages: Russian and Ukranian.

Many thanks to all translators for their help with this effort!

Our last major release was made just weeks before the Russian invasion of Ukraine shocked the world. We would like to take this opportunity to bring to mind that this sad situation is ongoing. It directly affects some of the contributors and users of our project, and many individuals, families and communities. Please consider what you can do to help them.

Other changes

We only listed a handful of the main features here. The reality is that beneath the hood, we have made a large number of changes to improve security, performance and reliability. And we have in place the foundations for other exciting things we have in the pipeline!

Installing and upgrading

Choose your adventure:

If you’re new to Snikket, you can head straight to the setup guide for instructions on how to get started.
To upgrade an existing self-hosted instance to the new release, read the upgrading guide.
Customers on our hosting platform can expect the new release to be rolled out soon, we’ll be in touch! If you have any questions, you can contact support.

Happy chatting!

P.S. If you’re planning to be at FOSDEM in a few weeks, we’ll be there, come and say hi! We’d love to meet you :)

On the jabber.ru MITM attack

team@snikket.org (Snikket Team) — Sat, 21 Oct 2023 16:30:00 +0000

This post is about a recent security incident on a public XMPP service, which provides jabber.ru and xmpp.ru. We have received a few questions from Snikket users about whether they should be concerned about the security of their own servers (Snikket also uses XMPP).

The good news is that Snikket was not affected by this incident - this was a targeted attack against the jabber.ru/xmpp.ru service specifically. Later in the post we’ll share more information about what we’ve done, and what we have planned, to ensure our systems are secure from such attacks.

What happened with jabber.ru?

It transpired yesterday that jabber.ru and xmpp.ru public XMPP services have likely been subjected to interception of their encrypted traffic for at least 90 days, and possibly up to 6 months. It is not clear who performed the interception, or why. Possibilities include law enforcement, or a compromise of the infrastructure of two hosting providers (Hetzner and Linode) used by the services.

This post won’t go into too many technical details, for which we would refer to the original write-up published here.

The “machine in the middle” (MITM) attack targeted the jabber.ru and xmpp.ru domains, and ended shortly after its discovery. We’re not aware of any documented attacks of this nature on the XMPP network before, nor indeed other internet services at this time.

Why is this news?

Although traffic interception is nothing new, previously it has mostly been performed by passively observing traffic as it passed through network devices on the internet. Snowden revealed how widespread this practice was back in 2013, prompting a large shift towards TLS encryption by default across the internet. TLS protects traffic from observers, and today it is used to protect everything you do online, from chatting, to checking your email, to online banking.

What makes this attack notable, is that it was an “active” attack - not just passing traffic through, but modifying it. Specifically, they were decrypting and re-encrypting traffic as it passed through a network device (the “machine in the middle”) that had been placed between the jabber.ru server and the rest of the internet.

Usually TLS prevents such an attack from succeeding, as long as you verify certificates. However in this case the attacker was able to obtain valid certificates for the targeted domains, making all connections look like they were genuine.

With the advent of ACME-based certificate authorities such as Let’s Encrypt, obtaining certificates is not at all hard for someone able to intercept and respond to traffic that is sent to your server, and in this case that’s exactly what happened.

It’s not, mostly. However, one thing we have in common is our hosting provider - we use Hetzner for a number of our servers, including those that power Snikket Hosting.

In response to the news of this attack, we have audited all our servers and verified that none demonstrate the anomalous characteristics reported by the jabber.ru team, confirming our belief that this was targeted only at their services.

We will be taking additional steps to safeguard our systems from similar attacks, as a preventative measure. This includes:

Deploying a strict CAA record, ensuring only our Let’s Encrypt account will be authorized to issue certificates for our hosted domains (we already have DNSSEC in place to help secure this). Update: The CAA record is now deployed.
Setting up monitoring to alert on any suspicious certificates issued for our hosted domains. We are not currently aware of suitable tooling that would meet our needs (though there are some existing efforts in this area, such as certspotter). If we develop anything new, we will share it with the community.

We are also currently working hard on the next Snikket Server release, which coincidentally supports the “channel binding” security feature. Channel binding is the ultimate protection against these kinds of attacks, and works even if the attacker is able to obtain a valid TLS certificate. The protection will be enabled by default on both hosted and self-hosted instances. This feature was part of our modern authentication and account security work in Prosody, funded by NGI Assure via NLnet.

Custom domains with Snikket

If you use a custom domain with your hosted Snikket instance, or if you are entirely self-hosting Snikket, you can also add a CAA record to increase security. You need to do this with your DNS provider - we cannot do it for you. We recommend using a relatively low TTL in case you make any mistakes.

Note that although it helps improve the security of your instance, setting a CAA record is entirely optional.

Custom domains on our hosting platform

If you are using our hosting platform, your CAA record contents should look like this exactly:

128 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/75887657"

You only need to set it for the main domain of your Snikket instance. If you use your domain for other things, do not add this CAA record on your root domain! E.g. If your Snikket instance is at ‘chat.example.com’, your CAA record should also be at ‘chat.example.com’. Otherwise it will prevent you from obtaining certificates for your other services.

Self-hosted instances

If you are self-hosting Snikket, you can also set a CAA record, but you will need to use your own account URI. You can run the following command in your snikket directory to find the right URI to use:

docker-compose exec snikket_server find /snikket/letsencrypt -name regr.json -exec grep uri {} +

Remember to set the CAA only on the domain or subdomain you use for Snikket. Put the URI (the part beginning with https://) into the record, replacing URI-GOES-HERE in the example below:

128 issue "letsencrypt.org;accounturi=URI-GOES-HERE"

If you have a reverse proxy in front of your Snikket instance that obtains its own certificates independently from your Snikket setup, you should add an additional CAA record in the same format with the accounturi that your reverse proxy uses.

After putting the CAA record in place, keep a close watch on Snikket and any other services on your domain over the following weeks, to ensure they successfully renew their certificates.

We hope this post has been helpful! If you have any questions about your Snikket setup, we have a helpful community chat. If you are using our hosted platform, you can also contact us via email at support@snikket.org.

State of Snikket 2023: Funding

team@snikket.org (Snikket Team) — Mon, 18 Sep 2023 13:20:00 +0000

As promised in our ‘State of Snikket 2023’ overview post, and teased at the end of our first update post about app development, this post in the series is about that thing most of us open-source folk love to hate… money.

We are an open-source project, and not-for-profit. Making money is not our primary goal, but like any business we have upstream expenses to pay - to compensate for the time and specialist work we need to implement the Snikket vision. To do that, we need income.

This post will cover where our funding has come from over the last couple of years and where we’ve been spending it. We’ll also talk a bit about where we anticipate finding funding over the next year or so, and what some of that is budgeted for.

Our last post on this topic was two years ago, when we announced the Open Technology Fund grant that allowed SuperBloom (then known as Simply Secure) to work on the UI/UX of the Snikket apps. Since then, other pieces of Snikket-related work have been supported by two more grants - both from projects managing funds dedicated to open source and open standards by the EU’s (Next Generation Internet) initiative.

The first one was a project called DAPSI (Data Portability and Services Incubator), focused on enabling people to move their data more easily between different online services. DAPSI funded Snikket directly to support Matthew’s work on account portability standards, which can be used not only in the software projects underlying Snikket itself, but any and all XMPP software. This one helped keep Matthew fed for much of 2021, and as we described on our blog after the funding was confirmed, it kept him busy with:

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

The other grant was from the NGI Assure Fund administrated by NLnet. It was one Matthew applied for on behalf of the Prosody project, and helped keep him busy and fed through the second half of 2022 and into 2023. Prosody is the XMPP server project that the Snikket server software is built on, so any improvements there flow fairly directly to people using Snikket.

NGI Assure is focused on improving the security of people’s online accounts, and their grant to Prosody was for work on bringing new security features like multi-factor authentication to XMPP accounts. The work included in the scope of the grant is now complete, and some of it is already available to be used. The rest will be boxed up over the coming months and released, to start finding its way into XMPP software.

Both of these successful grant applications are practical examples of the Snikket company serving as a way to fund important work on the software and standards that the Snikket software and services depend on. Work that can be hard to fund any other way. However, grants like these usually cover a medium-to-long-term piece of work with a very specific scope, which can divert time away from other parts of the project. It is hard to find grants with a focus on general improvements, bug fixing and maintenance. This is the main reason why there hasn’t been as much work on the app side of things, nor updates on this blog.

We very much appreciate the grants we’ve received from all these funders, and the important features they have enabled us to implement. But ultimately we see “side income” like grants as a short-term way to plug the holes in our financial bucket while we’re still getting up and running. Our long term goal, as a social enterprise (specifically a UK-based Community Interest Company), has always been to earn the income we need through donations and by providing commercial services to the community using Snikket software.

When Snikket began, the main plan for this was to set up a hosting service, where people can pay a regular subscription to have us look after their Snikket server (more on this below). But over the last year or so we’ve discovered that there’s a lot to be gained from partnering with other social enterprises with shared values and related goals.

One such company is JMP.chat, an innovative telephony company who provide phone numbers that can be used with XMPP apps, for both text messages and calls. They recently celebrated JMP’s official public launch a few months ago.

We’re very grateful to JMP for funding the other half of Matthew’s work hours while he was beavering away on the NGI Assure grant work. Why were they willing to do that? To answer that, we need to tell you a bit more about what they do.

During the six years their service has been in beta testing, JMP’s first priority has been developing software gateways to allow XMPP apps to communicate with mobile phone networks, and vice-versa. However, many of their customers are newcomers to the world of XMPP. They would often struggle to find suitable apps with the required features for their platform, and struggle to find good servers on which they can register their XMPP accounts.

What could be a better solution to this problem than a project that aims to produce a set of easy-to-use XMPP-compliant apps with a consistent set of features across multiple platforms? Yes - Snikket complements their service wonderfully!

So we have been collaborating a lot with JMP (or more generally, Soprani.ca - their umbrella project for all their open-source projects, including JMP). On the app development side, we share code between Snikket Android and their Cheogram Android app (both are based on, and contribute back to, Conversations). We have also worked to ensure that iOS is not left behind, integrating features such as an in-call dial pad to Snikket iOS as well.

If JMP customers don’t already have access to a hosted XMPP server and neither the time or skills to run their own, they need one of those too. So JMP have been suggesting Snikket’s hosting service to customers who don’t have an XMPP account yet. With all the necessary features for a smooth experience, easy setup and hosting available, Snikket ticks all the boxes. In fact the latest version of Cheogram allows you to launch your own Snikket instance directly within the app!

A lot of work has been put into ensuring the hosting service is easy, scalable and reliable - to be ready for JMP’s launch traffic and also well into the future.

But while JMP is an excellent partner, Snikket isn’t only about JMP. We’re preparing for our own service to also exit beta before the end of this year. Once we do, revenue from the service will help us cover the costs of continuing to grow and advance all of our goals. Pricing has not been set yet, but we’re aiming for a balance between sustainable and affordable.

JMP will continue to sponsor half of Matthew’s time on the project. The other half is covered by our other supporters. You know who you are and we’re very grateful for your support.

The income sources we’ve talked about so far pay for Matthew’s time to work on Snikket and related projects. We also appreciate the donations a number of people have made to the project via LiberaPay and GitHub sponsorships. These help us pay for incidental expenses like;

Project infrastructure, including this website, domain names, and push notification services and monitoring.
Development costs, like paying for an Apple developer account.
Travel costs of getting to conferences for presentations.

One other important thing these donations help to pay for is test devices.

We buy, or are donated, second-hand devices for developing and testing the Snikket apps. Used devices are much cheaper, so we can get more test devices for the same budget. Also, most people don’t get a brand new device every year, so these slightly older devices are more likely to match what the average person is using.

Finally, we consider the environmental benefit. Using older but functional devices gives them a second life, preventing them from being needlessly scrapped, and keeping them out of the growing e-waste piles our societies now produce.

So that’s everything there is to share on the topic of Snikket’s finances for now. But we’re not done with our ‘State of Snikket 2023’ updates, oh no.

As we mentioned at the end of the last piece in this series, there’s at least one more coming, about new regulations for digital technology and online services. A number of governments around the world are passing or proposing laws that could affect Snikket - some of them a bit concerning - and we have a few things to say about them.

We’re also going to sneak in a review of the inaugural FOSSY conference Matthew presented at recently.

Watch this space!

State of Snikket 2023: The Apps

team@snikket.org (Snikket Team) — Wed, 09 Aug 2023 14:05:00 +0000

As promised in our introduction to the series, welcome to the first of our ‘State of Snikket’ update posts! This installment features all the app development news you could wish for.

So what’s new in the world of Snikket apps?

UI/UX

If you’ve been following Snikket development for a while, you might remember that we were receiving UX advice on making our apps easier and more fun to use, thanks to the team at Simply Secure. Recently they’ve been busy with a UX transformation of their own, including renaming themselves SuperBloom. From the blog post announcing this on their website:

“A superbloom is a rare event, when long-dormant wildflower seeds bloom together to transform a harsh landscape with renewed energy and resilience. We believe technology design is at a Superbloom inflection point, and we’re excited to be shaping it into a beautiful future.”

We’re pleased to have them working with us again, creating some mock-ups (or “wireframes”) for updating the look and feel of the Snikket apps.

These will guide the ongoing evolution of our existing Android and iOS apps, and we plan to use them when we begin prototyping web and desktop clients, using the new Snikket SDK (more on that later).

So what about the existing apps?

iOS

The release of our iOS app was the last big news we shared on the app front, and Snikket iOS was warmly welcomed! However it’s also fair to say it has had a couple of teething problems and is still a bit less polished than our Android app.

Some of these issues are due to various constraints in iOS, requiring apps to be designed very differently to apps on other platforms. We have also had difficulties finding people who are familiar with both XMPP and iOS development, and who have time and motivation to work with us on Snikket for iOS.

Nevertheless, we have a good relationship with the developers of Siskin - which our iOS app is based on - and we’ll continue to work on improving it. If you’re keen to help, we’re always looking for additional beta testers.

Android

Meanwhile our Android app, the first app we released, continues to be widely used. It derives from Conversations by Daniel Gultsch (iNPUTmice, also creator of the Ltt.rs email app for Android). We also maintain a good relationship with Daniel, and keep a close eye on upstream improvements.

In fact, our app follows Conversations so closely that maintaining it as a build flavour upstream is under consideration as a potential option for the future. That would automate some of the work of releasing new versions, allowing us to bring new Conversations features and bug fixes to people using Snikket more quickly.

Speaking of new features, the release of Conversations 3.0 will come with a whole Santa sack of them (nitty-gritty technical details here), which will eventually make their way into Snikket on Android.

Some of the anticipated features include emoji reactions, multimedia messages, improved message editing (including edit histories), and full support for replies, which Daniel says will include allowing us to jump to the original message that was replied to.

Another big change is in the handling of attachments, such as photos and files sent in chats. Once Snikket is rebased on Conversations 3.0 these will be invisible to other apps on your device, unless and until you choose to export them. Just as you’d expect when they arrive in chats that are end-to-end encrypted, to protect your privacy.

One change that we’re really excited about will finally bring the concept of Snikket’s circles to the app’s interface. This will allow people to easily filter their chats, for example between “Family”, “Friends” and “Work”. If you join a circle - for example one called “Family” - everyone in the Family circle will automatically be added to your contact list, and you’ll be added to theirs.

After Conversations 3.0 is released, we’ll be able to group the chats associated with each circle together in your contact list, rather than having them all mixed together as they are now. Once the new interface arrives, you can safely share dank memes with your gaming friends in the “Game Night” circle, with confidence they won’t be accidentally shared with your family.

So when will all these new features arrive?

Initial plans aimed for a November release, but it’s well established that software development can be unpredictable. Especially in the open-source world where maintainers are often stretched between many responsibilities. So even if it takes a bit longer to spit and polish, we’re not worried - and we’re fairly confident the first version of Snikket based on it will be appearing next year. Watch this space!

Okay, we’ve covered Android and iOS. So what about these web and desktop apps we’ve listed as a goal of ours for some time?

With more development time becoming available (more on that in a future post), we’ve been exploring how we might finally make these a reality.

The future of building Snikket apps

One such exploration has resulted in a prototype ‘Snikket SDK’ (Software Development Kit).

“A what now?”

Basically, it’s a cross-platform library that can handle all the digital smoke signals involved in communicating with an XMPP server. It presents developers familiar with other chat APIs with an expert smoke signal interpreter, which they can connect to any chat app interface they design.

Our hope is that this will make it easier to develop Snikket clients for the web, desktop, and potentially other platforms. This includes mobile GNU/Linux devices like the PinePhone, used with interfaces like Phosh by distros like PureOS, Mobian, and postmarketOS.

If this works out, whenever we make improvements to the SDK they can easily be shared by all the apps using it, massively reducing the work involved in supporting apps for an increasing number of platforms. But let’s not get ahead of ourselves.

So far its an early prototype - we haven’t even made a final decision on programming language yet.

Currently, we’re experimenting with Haxe, which can be compiled to a number of other languages, including JavaScript. Using this approach will allow us to build on existing XMPP libraries for the target platforms.

By providing an easy-to-use development kit with all Snikket’s features already implemented, we hope to make it easier for per-platform development to focus on just the UI/UX layer, instead of getting dragged down reimplementing XMPP and business logic for every platform.

It’s important to note that we are not aiming to produce another XMPP library - many of those already exist. Rather, we’re focusing on a layer above that - an SDK that allows developers to easily work with a Snikket (or compatible XMPP server) with zero knowledge of how XMPP works.

We’ll share additional progress as it happens, so once again, watch this space!

That’s all the news we’ve got for today.

The next post will focus on the work we’ve been doing to set up hosting of Snikket servers as a human-friendly subscription service, and an ethical source of ongoing funding for Snikket development. It will also cover how Snikket has been funded so far and what we’ve been spending the money on.

After that, we’re planning to take you on a deep dive into new laws like the Digital Markets Act in the EU - and a similar ones in the UK and elsewhere - and how they could impact social enterprises like Snikket, developing Free Code software for use in decentralised networks. There’s potentially some good news here and some rather worrying news.

So keep an eye out for those over the coming weeks.

State of Snikket 2023

team@snikket.org (Snikket Team) — Wed, 09 Aug 2023 14:00:00 +0000

This is our first blog post for quite a while, and the last few have all been technical updates of various kinds about the Snikket software. In fact it’s been almost two years since the last post that gave a general progress update on the Snikket project itself, so let’s fix that!

You’ll be pleased to hear that Snikket is very much alive, and although there hasn’t been much of a show to see here, a bunch of stuff has been going on backstage.

We plan to catch you up with our progress and various other topics through a series of upcoming blog posts. A number of these are inspired from questions we receive often, others are related to updates in the project, or changes in the industry and ecosystem which Snikket is a part of.

Rather than cram a diverse range of topics into a single post, we’re going to break it up a little. Over the coming weeks, we’ll answer questions such as:

What have we been working on over the last year?
What is the status of the Android and iOS apps?
What about the web and desktop apps we’ve been promising?
What did JMP.chat launch and what does that have to do with Snikket?
Where has funding come from to keep the lights lit at Snikket HQ?
What are the longer term plans for project funding?
What’s this Digital Markets Act thingy, is it good or bad, and what implications does it (and other similar laws in the pipeline) have for the future of Snikket, XMPP, interoperability of chat apps, and decentralised online services more generally?
What did we get up to at the recent FOSSY conference in Portland, US?
What kind of test devices do we use and where do they come from?

Curious? Our first post is live, and it’s about the app development. Jump right in to State of Snikket 2023: The Apps!

F-Droid security update

team@snikket.org (Snikket Team) — Sun, 11 Dec 2022 10:00:00 +0000

Last week, Snikket Android users who installed the Snikket app via F-Droid started receiving a warning that it contained a security vulnerability. This wasn’t entirely accurate, as the problem wasn’t with the Snikket app itself but specifically F-Droid’s own build of the app that was using an outdated version of the WebRTC library.

As of today, F-Droid have published a new build (2.10.3) of the Snikket app that now uses an up-to-date version of the WebRTC component. The new WebRTC was built by us and published to Maven Central, one of the sources that F-Droid trusts for certain pre-built dependencies.

Like many communication apps, Snikket uses WebRTC for audio and video calls. We’ve been working on finding a way for F-Droid to build Snikket with a more up-to-date version of the WebRTC library that meets the constraints of their build processes and policies. We’re happy that this work has paid off!

We’d like to thank Licaon_Kter from F-Droid for support and guidance in finding a suitable resolution to the problem. Also thanks to Danilo Bargen from Threema, who worked on incorporating Threema’s existing WebRTC build scripts into a project publishing plain unmodified builds of the library. Our own WebRTC build process has been derived from these projects.

We’ve confirmed that our new WebRTC build will also be adopted by upcoming builds of the Conversations and Cheogram apps in F-Droid, and it is also available to any other XMPP app that would prefer to use it instead of Threema’s patched version or maintaining their own.

There is likely to be more work on this area in the future. In the long term, the ideal solution will be F-Droid building WebRTC themselves, as they do with apps that they publish. However this requires resources - both technical expertise and computing power. If it sounds like something you could help the F-Droid team with, check out this issue for more information or to follow along on their progress.

Finally, this positive news goes further than just resolving the security warning. The older version of WebRTC that F-Droid was using for Snikket builds was adding some friction that prevented us from easily merging new changes from Conversations (the upstream project for the Snikket Android app). With a new WebRTC in place, it will now be much easier to regularly synchronize the Snikket app with all the new improvements in Conversations once again.

(P.S. Did you know that the Conversations project recently announced funding from NLnet to support Conversations 3.0, a major new milestone in the project’s development - we’re super excited!)

We’ll be sure to share details of new updates here in the future. Meanwhile, if you’re using Snikket F-Droid… go update! :)

Notes on the F-Droid security warning

team@snikket.org (Snikket Team) — Thu, 08 Dec 2022 10:00:00 +0000

Update 2022-12-11: A new update (2.10.3) is has been published, and the security warning should clear after installing this update.

Snikket Android users who installed the app via F-Droid may receive a warning from F-Droid telling them that the app has a vulnerability and that they “recommend uninstalling immediately”. First of all - don’t panic! This is a over-simplified generic warning that is scary, but the actual situation is not quite so scary and has an explanation. Here goes…

How F-Droid works

When an app is developed and ready for release, it must be compiled and built, to produce the final app file (e.g. APK) that can be installed on devices.

Most app stores let developers upload their built apps. For example, we build the Snikket on our build servers and then upload it to Google Play.

However, F-Droid is different. Instead of accepting ready-built apps from developers, they instead download the app’s source code and build it themselves. This has a number of advantages: you can be sure that every app in F-Droid has source available, and (as long as you trust the F-Droid folk and systems), you know the app you install matches exactly the published source code and hasn’t got any surprises.

WebRTC woes

The Snikket app, along with many other apps supporting audio/video calls on Android, depends on an open-source WebRTC component developed by Google as part of the Chromium project.

However, building the WebRTC component is not trivial. It requires a lot of system resources, downloading many gigabytes of source code, and the process uses some Google-specific build tools.

Rather than attempt build WebRTC from source, the F-Droid build process has historically been pulling in third-party pre-built versions of the library from other sources. Originally these builds came from Google’s Maven repository, but Google announced they would no longer publish new WebRTC builds some time ago (the source code continues to be available and updated of course). Many F-Droid apps have remained stuck on an old version of WebRTC due to this, and the F-Droid project has remained without the resources needed to build WebRTC reproducibly from scratch as part of their usual build pipelines.

In August 2022, a lot of apps in F-Droid were switched to a newer (but still third-party) build of WebRTC, published by the Threema developers. Unfortunately, this build is patched and optimized for Threema’s usage of WebRTC in their app. As a result, their build has poor interoperability with software and services in the XMPP ecosystem, including the popular JMP service. When asked if they would consider tweaking their build to improve interoperability they (quite reasonably) declined, stating that the build is really only intended for their own app.

Meanwhile, WebRTC is a complex and widely-used component. Security researchers have found multiple vulnerabilities. However, WebRTC is technically developed as part of the Chromium web browser project (the open-source version of Google Chrome), and this is the context in which most of the vulnerabilities have been discovered and reported. Chromium exposes the WebRTC API to every web page you visit, while the usage of WebRTC in mobile apps such as Snikket is significantly more restricted.

While it’s not ideal to be using an old version of WebRTC, we are at this time unaware of any security issues in the build that F-Droid is using that would impact Snikket and the way it uses WebRTC. F-Droid’s security warning has been added to a wide range of apps using WebRTC as a precaution (not just Snikket), but at no point have any of the apps confirmed to be specifically vulnerable to any of the issues.

Tip: WebRTC is generally a complex component. If you do have any concerns about WebRTC security (in Snikket or any mobile app) and believe you may be specifically targeted, we recommend to avoid answering unexpected calls from strangers. Although we are not aware of any existing issues, past issues have generally required you to accept a call from a malicious party before any exploit can take place. Therefore any attacker would first need to know your Snikket address and rely on you accepting their call.

What can you do?

We’re actually close to finally resolving the issue, with the co-operation of F-Droid contributors, and are hoping we can get an update to Snikket (and other apps in the same situation with WebRTC) published by F-Droid very soon.

In the meantime, you have the following options:

Simply press ‘Ignore’ on F-Droid’s warning for now, and wait for their builds to be fixed. This is the recommended course of action for most existing F-Droid users.
Alternatively, switch to builds provided by us, using Google Play or Aurora store. These are built with a modern WebRTC version. Note that these builds also include libraries from Google to support push notifications. If you are running a pure “de-Googled” Android variant, you won’t want these builds and they may not work correctly on such devices anyway.

As a third option, we’re looking into setting up our own F-Droid repository where we would be able to publish our own official FOSS builds with a modern WebRTC version. This is not currently available, but we’ll be sure to announce it here and on our social media when it’s ready.

Conclusion

We greatly value the role F-Droid plays in mobile app distribution and security on Android. We still believe that it is generally the best option for most users who care about open-source values to install apps on their device.

However, in this case an ongoing issue with their build processes and policies has turned into an unnecessarily alarming recommendation to uninstall the app without sufficient explanation to users.

We’ll continue working with F-Droid to resolve the issue for Snikket and all the other apps affected, and are looking forward to sharing news of updated builds with you soon!

Update: The good news is here!

Server updates for ARM systems

team@snikket.org (Snikket Team) — Tue, 01 Feb 2022 10:00:00 +0000

We have a couple of important announcements relevant to people running the Snikket server software on ARM devices, including Raspberry Pi. Systems using ARM processors are increasingly popular for self-hosting due to their increased efficiency, lower cost and minimal energy consumption.

The Snikket January 2022 server release was an exciting release for us, but some users on ARM-based systems reported some difficulties upgrading to the new version.

Web interface ARM compatibility

Due to a couple of issues with the way our new release was built, the release for certain ARM devices did not include all the necessary components for the web interface to start. If you are affected by this, you may notice the web portal being unavailable on your instance after upgrading. Inspecting the logs may reveal failure to load the module “aiohttp”.

We have fixed our build process, and pushed an updated release. Although the new version is available for all platforms (not only ARM) the only other changes are some translation improvements in the web portal.

To upgrade to the new release, see our upgrade guide.

Compatibility with Debian 10

The second issue we discovered is that users with systems running Debian 10 or Raspbian 10 (“buster”) may encounter an issue where the service fails to start. Inspecting the logs may reveal errors such as “permission denied” or various errors related to “time”.

The container security rules supplied in Debian 10 are out of date. The old rules do not allow access to modern methods of requesting the current time from the system (the current time is necessary for a range of functionality, including verifying certificates are not expired).

Luckily there are a couple of options to fix it. For example, just upgrading your system from Debian/Raspbian 10 to 11 will automatically resolve the issue. Alternatively, if you’d like to avoid upgrading your system right now, a fixed package has been provided by the Debian backports team. We have full details in our troubleshooting guide.

If you have any trouble upgrading on any platform, feel free to stop by our community chat and we’ll be happy to help you out!

January 2022 server release

team@snikket.org (Snikket Team) — Wed, 19 Jan 2022 12:45:00 +0000

New year, new Snikket: We’re excited to introduce a new release of the Snikket server! The Snikket server is an easy-to-install server package that allows you to run your own private messaging service for family, friends and other small groups.

The main focus since the previous server release in November has been on the DAPSI-funded Account Portability feature, which allows people to export and import account data for backup and migration purposes.

For information on how to upgrade from a previous release, see our quick upgrade guide.

Account import and export

Last year, we announced that we had been selected for funding to improve the state of account portability/migration in Snikket and XMPP. You can read more background information about this project at the XMPP Account Portability project homepage on Modern XMPP. This release finally introduces the results of our work on this project in Snikket.

Snikket users can export their account data from within the web portal. A new “Manage your data” button provides easy access to the export functionality. This can be used for backup purposes or to take account data to another service provider.

The data is exported in a standardized format which can be supported by any XMPP server, further strengthening the interoperability of Snikket with other existing XMPP-based chat services.

After successful registration via the web portal (not via the app yet), new users are offered a form where they can upload their account data. This data could come from a Snikket server or another compliant XMPP server, allowing users to more easily move to the Snikket ecosystem of small, federated instances.

A glimpse of the new import and export interfaces

We are very grateful for the support of the NGI DAPSI team and the EU funding that allowed us to complete this important piece of our roadmap!

Improved resource monitoring

Our previous release introduced metrics in the web admin dashboard (the “System Health” section), and the ability to export those to monitoring systems such as Prometheus via the OpenMetrics API. This release includes more improvements in this area, including more accurate memory usage monitoring, and Snikket can now also report the amount of storage used by file uploads.

Internal changes

We’ve upgraded the Snikket Docker images from Debian 10 to 11. We’ve also upgraded Prosody, which brings a whole bunch of changes, including reduced memory usage and a more robust DNS implementation. This release should also restore update notifications, which have been unreliable in some previous versions.

Installing or upgrading

If you’re new to Snikket and want to try out the new release, check out our quick-start guide. If you already use Snikket, head over to our upgrade guide!

Folks using our hosting service, the new release will be available in your dashboard in the next day or so.

Our next focus will be on polishing the next version of our iOS app, so we can release a lot of exciting improvements to app store users. Stay tuned for another post about that soon. Meanwhile… happy chatting! :)

Update 20/01: A small hotfix was pushed to the release to solve a lingering issue with update notifications.

Update 31/01: Systems running Debian 10 or Raspbian 10 on ARM should review our upgrade notes before installing this release.

Snikket Server - 2022-01-13 security release

team@snikket.org (Snikket Team) — Thu, 13 Jan 2022 14:00:00 +0000

Snikket Server - 2022-01-13 security release

A security flaw has been found and fixed in a core component of the Snikket server software, Prosody. A fix has been released today, and it is recommended that everyone upgrades as soon as possible to receive the fix.

The flaw would allow an attacker to trigger the Snikket server to consume extreme amounts of resources (CPU and RAM), resulting in a denial of service.

Upgrading

You can find instructions for upgrading to the latest release in our upgrade guide.

If you are a Snikket hosting customer, you will receive an email with information about upgrading your instance.

Questions

What is a “Denial of Service” attack?

A “Denial of Service” attack (DoS) is any attack that causes an internet service (such as Snikket) to become unavailable to its users, i.e. unable to handle requests. In Snikket’s case, this means users would be temporarily unable to exchange messages, make calls, or share media and files.

Is any data at risk?

This flaw does not expose any data to the attacker. It simply causes Snikket to consume large amounts of memory and stop responding.

What is the impact of this issue?

Snikket may use large amounts of CPU and RAM while trying to handle traffic that has been specially crafted by an attacker to trigger this flaw. If Snikket is running on a server alongside other services, Snikket’s excessive use of resources may negatively impact those services as well.

How was this issue discovered?

The issue was discovered by the Prosody development team during a review of the code. It is not known to have been actively exploited by anyone. However, now that the fix has been published, it may bring more attention to the flaw. It is recommended that you upgrade as soon as possible.

What other changes are in this release?

This security release only contains changes that fix the security issue. No features or other fixes have been introduced in this release.

Is there a workaround?

If you cannot upgrade immediately, you can run the following command in your Snikket directory (where docker-compose.yml is located) to disable WebSocket support temporarily:

docker-compose exec -it snikket prosodyctl shell module unload websocket

WebSockets are enabled by default, but not used by any of the official clients; they are only needed for Web-based clients. Web-based clients should in addition be able to (be configured to) fall back to the unaffected BOSH endpoint.

Note that the above workaround is temporary - it will be reset if you restart Snikket for any reason. It is recommended to upgrade Snikket to achieve a permanent fix.

How can I tell if my version is affected?

The fix has been released in ‘beta.20220113’.

To check your version, log in to the Snikket web portal with your admin account. Then click on the “Snikket service” text at the bottom of the page. View the section “Software Versions” and ensure that the ‘Prosody’ component reports Snikket test 48-3d061. If you see 0.dev, 37-e5d49 or any number lower than 48 then your Snikket is not up to date yet. Follow the upgrade guide.

Further information

If you have any questions or concerns about this release, you can join the Snikket community chat or contact us directly.

References

Original Prosody advisory

November 2021 server release

team@snikket.org (Snikket Team) — Thu, 18 Nov 2021 17:45:00 +0000

We’re excited to introduce a new release of the Snikket server! The Snikket server is an easy-to-install server package that allows you to run your own private messaging service for family, friends and other small groups.

Since the previous server release, we’ve been focusing our work mainly on the Snikket apps, especially the first release of our iOS app. We’ve continued work on the server part of Snikket though, and we’re glad to share a range of new improvements with you now.

For information on how to upgrade from a previous release, see our quick upgrade guide.

iOS improvements

In case you missed it, we released the first version of our iOS app to the app store a couple of months ago. We’ve been continuing to develop the app, and more releases are already in the pipeline.

Upon the app’s initial release there were still a few “rough edges”, such as the lack of notifications for group messages while the app is closed. Fixing a number of these issues required work on the server, and so that has been a big focus of this release.

In particular:

Encrypted messages show a nicer notification (“You have received an encrypted message”). Displaying the contents of encrypted messages without opening the app is not yet possible, but is planned.
The app can now show notifications from group chats even while the app is closed. A couple more small changes are required before this works seamlessly, and these will be included in a future app update.

Now that these issues are resolved, a link to the iOS app will be shown by default on the Snikket invitation page, starting from this release.

You can now share files up to 100MB using Snikket! Previously this was limited to 16MB for technical reasons. Although most shared files are much smaller than 16MB, there is the occasional need to share larger files. Now you’re covered.

To help server operators plan their system resources, it’s now possible to set a service-wide quota for the storage of uploaded files. This means that even if your users have a little too much fun with the new limits, you can be sure your system won’t run out of disk space.

Limited accounts

In the previous release we introduced the ability to select whether an account is an administrator or a normal user. In this release we add one further type: “limited” accounts.

A limited account has a number of restrictions. In particular they:

may only communicate with users and group chats on the same server,
may not create public channels,
may not invite new users to the server.

The purpose of limited accounts is to allow you to grant use of the server for communication with other users of the server only. This can be applied to accounts for children or guest users, for example.

For more information, see the documentation on User Roles.

Resource monitoring

The web admin dashboard now shows some basic statistics about your server resources, such as system load and memory usage of the various Snikket components. This can be helpful to ensure Snikket is performing well and you have enough resources available to serve your users.

Screenshot of the resources panel in the Snikket web interface

Server announcements

In the same system health area of the admin dashboard, you can also now send an announcement message to all users of your server - e.g. to inform them about upgrades and maintenance.

Support and questions

As usual if you need any help or have questions about the new release, you’re welcome to join our community chat where folk will be glad to help you out.

Stay tuned for more upcoming releases, and… happy chatting!

Snikket iOS app now publicly released

team@snikket.org (Snikket Team) — Tue, 31 Aug 2021 14:00:00 +0000

This is the announcement many people have been waiting for since the project began!

Opinions are often strong about which is the best mobile operating system. However, while it varies by region and demographic, wherever you are it’s very likely that you have Apple users in your life, even if you don’t use one yourself. We want to ensure that the platform you use (by choice or otherwise) is not a barrier to secure and decentralized communication with the important people in your life.

The lack of a suitable client for iOS was an obstacle to many groups adopting Snikket and XMPP. For this reason, today’s release of a Snikket app for Apple’s iPhone and iPad devices is a significant milestone for the project.

A community effort

It’s a journey that began late last year with the announcement that we would be sponsoring support for group chat encryption in Siskin IM, the open-source iOS XMPP client developed by Tigase.

The Tigase folk have been very supportive of our project, and I’d like to especially thank Andrzej for his assistance and patience with all my newbie iOS development questions!

There are many other folk who have also helped unlock this achievement. This includes everyone who helped to fund the development work - especially Waqas Hussain, the kind folk at jmp.chat and of course absolutely everyone who has donated to the project. The majority of donations are anonymous so it’s impossible to thank everyone individually, but the amount of support we’ve received as a project is amazing, and really gives us confidence in achieving even more ambitious milestones in the future.

Funding aside, we couldn’t have refined the app without help from our diligent beta testers - with particular thanks to Michael DiStefano, Martin Dosch, mimi8999 and Nils Thiele for their bug-catching and comprehensive feedback. Everyone participating in the beta programme has helped shape the app we’re releasing today.

What happens now?

We’ll be rolling out a Snikket server update shortly that will add a link to the iOS app from Snikket invitation pages.

Update: The iOS app is now enabled by default since our November 2021 server release! The following step is no longer necessary.

If you’re eager to make the app available to your users before then, you can add the following line to your snikket.conf:

SNIKKET_WEB_APPLE_STORE_URL=https://apps.apple.com/us/app/snikket/id1545164189

After saving the file, apply the change with the command docker-compose up -d.

If you are using the Snikket hosting service, you will get an email soon that explains how to enable the app store link for your instances.

We’re not done yet

This is a big milestone, without a doubt. But we’re not completely done. The app is not perfect (yet!) and we’re still working on many things. But we believe this is no reason not to share it with the world as early as we can.

Push notification compatibility

The first thing to note (especially as many non-Snikket users will also be excited about a new iOS XMPP client on the scene) is that our primary focus has been on the app working seamlessly with Snikket servers. We’re committed to XMPP interoperability, but time and resources mean we can’t develop and test every change in pace with every XMPP server.

Although we expect it to generally work, there are some known compatibility issues currently. Specifically, due to the strict “no background network connections” policy for iOS apps, we have needed to adapt push notification handling slightly differently to what is supported on most XMPP servers today. The extensions we use are openly published by Tigase, and we have made available community modules for Prosody (mod_cloud_notify_encrypted, mod_cloud_notify_priority_tag and mod_cloud_notify_filters), and discussion has begun on moving these extensions over to the XMPP Standards Foundation standards process. We welcome help and contributions towards evolving XMPP’s current push notification support. If you’re interested, reach out!

Until then, although some backwards-compatibility considerations are in the app, this means it’s very possible you may experience issues with notifications on some non-Snikket servers when the app is closed (though Tigase servers and Prosody servers with the community modules enabled should be fine).

Language support

The app is currently only available in English, which is an unfortunate contrast from all other Snikket projects which are available in many languages already.

Updating the app to support translation of the interface is high on our priority list. After this is implemented, we will also be looking for help from translators, so stay tuned for further announcements.

Other work in progress

Other known issues that we are working on:

Update: These issues are now resolved in our November 2021 server release!

Notifications for OMEMO-encrypted messages show a potentially-confusing message about the app lacking OMEMO support. This will be fixed by the same server update that adds the app to the Snikket invitation page.
~~Group chat notifications are not yet working. This will also be rolled out as a future server update.~~

Of course, we will also soon be incorporating feedback from the usability audit and testing sessions when that work is completed.

I want to say a final thanks to our entire community for supporting the project. Snikket has ambitious goals, and the progress we’re making couldn’t be achieved without all the help and support we’ve received.

Drop us feedback about the app if you try it out, file bug reports and feature requests to help us with planning and, if you can, donate to help sustain the development of the entire project.

We look forward to welcoming more users to the XMPP network than ever before!

Improving Snikket's usability in collaboration with Simply Secure

team@snikket.org (Snikket Team) — Mon, 23 Aug 2021 10:00:00 +0000

One of the primary goals of the Snikket project is improving the usability of open communication software. We see usability as one of the major barriers to broader adoption of modern communication systems based on open standards and free, libre, open-source software. By removing this barrier, we open the door of secure and decentralized communication freedom to many vulnerable groups for which it was previously inaccessible or impractical.

Simply Secure is a non-profit organization working in user interface (UI) and user experience (UX) design. They specialize in combining human-centered design with the complex technical requirements of privacy-first secure systems. Our first introduction to Simply Secure was while contributing to Decentralization Off The Shelf (DOTS), a unique and valuable project to document and share successful design patterns across the decentralized software ecosystem.

Now, thanks to funding from the OTF’s Usability Lab, we’re pleased to announce that Simply Secure will be working with us over the coming months to identify issues and refine the UX across the project, with a special focus on our iOS app.

We’ve made a lot of progress on the Snikket iOS app recently, largely based on valuable feedback from our beta testers, and we are getting excitingly close to a general release. However there is still some work to be done.

The expert folk at Simply Secure will be performing a usability audit of the current app, as well as conducting usability testing, which is the study of how people use the app, and what struggles they face while completing specific tasks.

Using information from these analyses the Simply Secure team will assist with producing wireframes (sketches of what the app’s interface should look like) and actionable advice to improve the UX of the iOS app and Snikket as a whole. You will find information on how to participate later in this post.

What is UX anyway?

The modern UX design movement is a recognition that technology should be accessible and easy to use for everyone. Good design can assist and empower people, poor design can hinder and even harm people. The need for design goes far beyond making a user interface look beautiful. Software that is not visually appealing may affect someone’s enjoyment of an application, but an aesthetically-pleasing interface is not magically user-friendly.

Therefore designing for a good user experience is about more than just making the interface look good, it’s about considering how the software fits into a person’s life, what they need from the software (and what they don’t need) and how they expect it to behave.

These are tricky things to get right. Every user is different, and a broad range of input must be taken into consideration as part of a good design process.

UX methodologies

There are various ways to gather information useful for making informed decisions about UX improvements. A common easy and cheap approach is to add metrics and analytics to an app. This can tell you things like how often people tap a particular button, or view a particular screen. Developers and designers can use this information to learn which features are popular, which should be removed, or made more visible.

This approach has drawbacks. Firstly it only tells you what users are doing, it doesn’t tell you why they are doing it, or what they are thinking and feeling - for example if they are frustrated while looking for a particular feature or setting. Metrics can tell you that making a button more prominent increased the click rate, but it won’t tell you if half the users who clicked on the button were expecting it to do something else! This isn’t really going to give you enough information to improve usability.

Another significant drawback with a focus on metrics is the amount of data the app must share with the developers. People generally don’t expect apps on their device to be quietly informing developers about the time they spend in the app, what they look at and what buttons they press. Such data collection may be made “opt-in”, and there are modern projects such as Prio, working to bring privacy and anonymity to such data collection through cryptographic techniques.

A wildly different but much more valuable approach is to directly study people while they use the app - a technique known as “usability testing”. Unlike silent data collection, usability testing directly pairs individual users or groups with an expert while they are asked to perform specific tasks within the app. Although this requires significantly more time and effort it produces more detailed and specific insights into the usability of an interface.

Advantages of this kind of study include the ability to listen and learn more deeply the needs of specific types of users, particularly minorities whose problems could easily be drowned out by larger groups of users in a simple statistics-driven data collection approach. It also allows you to capture peoples’ thought processes, by asking them to explain each step as they complete tasks within the app.

Participation and looking forward

We can’t wait to begin our first usability testing facilitated by the experienced team at Simply Secure, and incorporate their findings into Snikket’s development.

If you’re interested in taking part, or know someone who would be a good fit for this project, we’d love to talk to you for 30 minutes to better understand how to improve Snikket. There will be no invasions of privacy as a result of this research. All identifying information will be removed. We will take all necessary and appropriate precautions to limit any risk of your participation. Anything that we make public about our research will not include any information that will make it possible to identify you. Research records will be kept in a secure location, and only Simply Secure and Snikket personnel will have access to them.

~~Appointment slots are available from 24th August to 3rd September.~~

Update: The usability testing phase of this project has now ended. Many thanks to everyone who participated, and helped spread the word!

May 2021 server release

team@snikket.org (Snikket Team) — Wed, 19 May 2021 12:45:00 +0000

We’re pleased to introduce a new release of the Snikket server. The Snikket server is an easy-to-install server package that allows you to run your own private messaging service for family, friends and other small groups.

As well as some new features, this release has some important security fixes for the built-in Prosody component. We advise all administrators to update as soon as possible.

For information on how to upgrade, see the (very short) upgrade guide.

Web interface

User and role management

This release brings a new interface for viewing and editing user accounts on the server. Among the changes is the ability to select the “access level” of an account via the web interface. In particular this allows you to add/remove other administrators of your server.

In the future we will also be adding an additional ’limited’ access level that can be used to restrict access to features such as invites and federation for certain user accounts (such as guests and minors).

Invitations

Invitation pages now include a link to download the Snikket app from F-Droid, as well as Google Play. Although F-Droid doesn’t yet support the seamless registration flow, it’s important that we help people discover free (as in freedom) alternatives whenever possible!

Translations

Translation improvements have been made for Polish, German, Danish, Spanish (Mexican), Indonesian and Swedish.

Certificate renewal

A bug has been fixed that eventually caused Snikket to present an expired certificate for web links (the web interface and also shared files). Restarting the service is a temporary fix, but this release will prevent it happening again in the future.

Technical improvements

Here’s a bunch of lower-level changes for advanced users that are included in this release:

You can now configure what address Snikket’s built-in HTTP server will listen for connections on (useful for certain advanced setups behind a reverse proxy)
Add docker health checks, allowing docker to inform you about the health of the Snikket services
Switch to a more robust DNS resolver (used for federation when connecting to other servers)
Allow configuration of an external TURN server (replacing the built-in one)
Fix support for BOSH and websockets (allowing third-party web clients)

If you have any questions or feedback about this release, let us know!

XMPP Account Portability funded by NGI DAPSI

team@snikket.org (Snikket Team) — Fri, 30 Apr 2021 13:14:48 +0000

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

What is DAPSI?

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

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

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

Data portability in Snikket and XMPP

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

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

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

In particular we believe:

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

The XMPP account portability project

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

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

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

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

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

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

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

Products vs Protocols: What Signal got right

team@snikket.org (Snikket Team) — Tue, 09 Feb 2021 12:51:00 +0000

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?’“

WhatsApp blog post “Why we don't sell ads“, June 2012

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.

Signal blog post “The ecosystem is moving“, May 2016

Well. Far from being frozen in time, XMPP has changed significantly in the past 20 years.

Just some of the things we have now that we didn’t have in the beginning:

End-to-end encryption using OMEMO (based on Signal’s protocol and audited), with multi-device and offline capabilities
Audio/video calling (now 2nd generation, encrypted, WebRTC-compatible)
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.

February 2021 server release

team@snikket.org (Snikket Team) — Tue, 02 Feb 2021 12:45:00 +0000

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.

A year is a long time on the internet! Since that initial announcement we’ve incorporated as a not-for-profit, formalized our goals and made significant progress towards them.

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!

Sponsoring Group Chat Encryption in Siskin

team@snikket.org (Snikket Team) — Mon, 30 Nov 2020 13:45:00 +0000

For some time XMPP has been in need of a good solution for Apple’s mobile operating system, iOS. In 2020 we now have a number of active projects. Work on the long-standing iOS (and now also MacOS) client Monal IM has really picked up in recent months, in no small part thanks to the efforts of tmolitor, who has been contributing a lot of modernization to both the UI and the internals.

Tigase also released an open-source iOS client, Siskin IM that has been making steady progress recently.

Monal IM

Siskin IM

It’s exciting to see so much activity happening around XMPP on iOS now, and both projects are adding more modern XMPP features with every release. Snikket does not currently have an official iOS client, so we’ve obviously been keeping a close eye on these advancements.

A major interoperability problem between the current version of Siskin and other modern XMPP clients is that it does not support end-to-end encryption (OMEMO) in group chats. This means that users of Siskin cannot participate in private group chats started by Conversations or the Snikket client on Android, because they are end-to-end encrypted by default.

OMEMO is a form of “end-to-end encryption”, which means that it hides message contents from the servers and operators of each chat participant. Siskin already supports OMEMO for one-to-one conversations, but not group conversations.

One of the goals of Snikket’s CIC is supporting and advancing the XMPP ecosystem. With that in mind, we’ve been working in recent months to obtain funding to close this gap in Siskin. Today we are pleased to announce that thanks to a private donor, the project can now move forward. The Tigase team will commence work on OMEMO in MUC in the coming weeks!

This is really exciting news, and will bring the XMPP experience for iOS users an important step closer to that of other platforms. There will be more announcements in the future, stay tuned!

If you want to help us with our goals and other projects like this, consider a donation, contribute in some other way, or simply help spread the word! The future of XMPP is coming :)

Snikket App Update 2.9.0

team@snikket.org (Snikket Team) — Tue, 03 Nov 2020 13:14:48 +0000

A new version of the Android app landed in Google Play and F-Droid this week. Snikket for Android 2.9.0 is based on Conversations 2.9.0 and sees a number of new features and improvements:

Audio/video call improvements

Firstly, there is now the option to leave a voice message if the person you are calling does not answer or is busy. Simply press the green voicemail button to record a message!

Snikket voicemail screenshot

There are also many small fixes and improvements, such as the ability to switch back to the chat view during the call, and using the loudspeaker for dial tone and busy tones when making a video call. Finally, a small number of specific devices produced echo during calls, this is now fixed.

Message search

As well as searching for messages across all your conversations, you can now also search within just a specific conversation. Simply go to the conversation you want to search in, and choose ‘Search messages’ from the conversation menu.

Notifications

A notification has been added when message delivery fails, so you know if your contact did not receive a message, even if you aren’t actively looking at their conversation. A bug was also fixed that meant notifications sometimes wouldn’t be shown in some circumstances.

Support for GPX files

If you’re a regular trekker, this one will be of interest to you. Although sharing and receiving logs of travels via GPX files was always possible in previous versions, they are now automatically identified and show up with a friendly icon. With a single tap you can easily open them in the app of your choice, such as OSMAnd or Trekarta (both open-source and available on F-Droid!).

Performance and bug fixes

Some other changes in this release include making it much quicker to restore your account from a backup file, and a fix for a bug that made it impossible to log in when your password included certain special characters.

That’s all for now. Grab version 2.9.0 of the Snikket app from F-Droid or Google Play!

As always, the Snikket app requires an invite or account on a Snikket service to get started. If you’re new to Snikket, learn more about the Snikket app to find out how to get started.

Announcing Snikket CIC

team@snikket.org (Snikket Team) — Wed, 28 Oct 2020 12:05:00 +0000

We’re pleased to announce that Snikket is now backed by a legal entity, Snikket Community Interest Company, registered in the UK.

A Community Interest Company (CIC) is a form of organisation that lies somewhere between a traditional limited company and a traditional charity. All CICs are “not for profit”, which means rather than focus on generating profits and increasing value for shareholders, they have other goals - serving a “community” in some way.

The exact “community” differs between CICs, but must be declared when the organisation is registered with the CIC regulator. Snikket’s “community interest statement” declares that the CIC is for the benefit of:

People and organisations in need of safe and private digital communication. This includes in particular family groups, clubs, local interest groups and other organisations that may be non-commercial in nature.

and that it will also:

[…] provide support to open and non-commercial projects that have similar objectives.

The the term social enterprise has been coined to cover this kind of organisation, regardless of the legal structure used (the options for which may vary from country to country). Although there is no strict definition of what a social enterprise is, they generally all have in common a goal of maximizing their “social impact” alongside or above generating profits.

And this is where a social enterprise formed as a CIC or similar structure differs from a traditional non-profit or charitable organisation. Although the laws vary between countries, a non-profit typically receives tax benefits in exchange for compliance with strict regulations about how it receives and spends its money. Such an entity is usually restricted from trading goods and services for example, and must rely 100% on donations to achieve its goals.

A CIC does not receive the same tax breaks as a charity, however it is free to trade in many of the same ways that a normal company would. This allows for more creative and sustainable ways to sustain the organisation financially, while the CIC protections ensure it keeps a focus on its social mission.

The legal structure of a CIC (particularly the variant that we chose for Snikket) means that it is not possible for us to sell shares, or raise money through venture capital. We feel that this is a good thing - VC funding introduces a certain pressure to ensure a good financial return on the investment. That expectation of return is precisely what makes VC money so very different to a donation (where there is no expectation of return) or a simple transaction where a service or product is received directly in exchange for the money. We wanted to take this option off the table.

What does all this mean for the project?

Well, having a dedicated legal entity means we were also able to open a bank account, which means we can finally accept donations and more easily fund various things. For example, we are seeking funding (e.g. through grants or donations) to help finish the iOS client (if you know anyone who may be able to help get this funded, get in touch!) And even the simple day-to-day expenses such as server costs are now able to be paid from the project’s bank account rather than my personal one. Obviously I’ll still be covering these costs for a while, but I hope in the long run that Snikket will become self-sustaining. This is the first step on that journey!

As for the future, don’t be surprised if we explore additional ways to raise an income - for example through offering services to Snikket users, such as hosting Snikket servers for people who are less able to run their own, or possibly services to help make running a Snikket at home easier. Contact us if you have an interest in either of these, or if you have ideas for other things we could look into offering.

As a not-for-profit, all income raised goes into Snikket and its objectives, such as funding development of the project and the projects it depends upon, and the ecosystem it is part of.

Want to contact us? Email team@snikket.org or join our chatroom.

Interested in learning more about starting a CIC or other form of social enterprise? See these resources:

International

Introducing Snikket

team@snikket.org (Snikket Team) — Sat, 24 Oct 2020 13:05:58 +0000

The Snikket project was officially unveiled earlier this year at FOSDEM in Brussels. We’re thankful to all the great feedback we received from people who came to see first-hand what we’re building.

What is Snikket?

For people who didn’t make it to the demo at FOSDEM, what is Snikket all about?!

Snikket is actually a collection of open-source components that together form a complete messaging platform that anyone can deploy. You can think of it as a self-hosted open-source alternative to commercial messengers such as WhatsApp, Facebook Messenger, Telegram or Signal.

Snikket provides:

A minimal-configuration server component that can be deployed onto your own system, either in the cloud or on your own device, such as a Raspberry Pi. Currently this is provided as a single Docker image, but we plan to add other distribution methods soon.
Software for users - currently we have an app for Android users (distributed via Google Play and F-Droid), and an app for iOS will be next to launch.

Who is Snikket for?

The primary audience for Snikket is people who want to set up their own safe, secure, and private realtime communication for small groups, such as families, communities, clubs and small businesses.

The mainstream alternatives to Snikket today are operated by commercial entities that profit from exploiting personal data gathered from their users. We believe that people should have the freedom to communicate on their own terms, rather than being forced to accept unacceptable privacy policies of a service just because their friends are using it.

We believe that everyone should have the choice of using a service run by someone that they trust. That is why we make running a Snikket server as easy as possible, and allow users of different Snikket servers to easily communicate with each other through a feature known as “federation”.

How does it work?

Snikket is based on the open standard messaging protocol XMPP. This means that we’re not inventing any fundamentally new technology (the world definitely has plenty of messaging protocols already!). In fact XMPP is a mature technology that has been in active developed for over 20 years. Because we are using an existing standard, there is a whole ecosystem of software that is compatible with Snikket. It also means that every Snikket server launched can immediately become a part of an existing global network of other XMPP-compatible servers.

The Snikket software itself is based on existing open-source projects. For example, the server component utilizes Prosody, and the Android app is based on Conversations. We are not forking these projects. Instead innovations that we introduce to Snikket are pushed upstream wherever possible. An example of this is the invitation based sign-up that we required to make signing up with a Snikket service as easy as possible. This involved creating a new extension to XMPP, and implementing it in multiple open-source projects, including Prosody and Conversations.

But why?

On hearing about Snikket for the first time, a question people often ask is, “why are you developing Snikket when plenty of XMPP software already exists?”

There are a number of reasons that Snikket’s existence is important.

Snikket aims to be an entrypoint for new users into the XMPP universe. This is something that a project that is just a client, or just a server, can’t do alone. We’re providing a complete package for people to get started easily even with zero knowledge of XMPP and how everything fits together.

Even for experienced users of XMPP, there are benefits to having such a package of integrated XMPP software. Knowing that Snikket client on platform A has the same set of interoperable features, same terminology, and same UX paradigms as the Snikket client on platform B makes for an attractive solution to many use-cases.

The design principles that Snikket adheres to can be found at modernxmpp.org, which is a parallel project aiming to align as many clients as possible in terms of UI/UX and protocol implementations. It is a natural extension to the Compliance Suites published by the XSF (but these only cover protocols, not features, terminology or UX).

Finally, since “Jabber” (the original user-friendly name for XMPP) is now a trademark owned by Cisco, it is unsuitable for use in many contexts and has been declining in recent years. However telling people to “use XMPP” (a protocol standard made for developers) leaves them confused and directionless. It’s a much better option to be able to tell people to “use Snikket”, which leads them to a suite of user-friendly XMPP software.

The future

There is a lot more planned! We have two primary focuses right now: launching an iOS client, and finishing the web interface for the server (so that users can manage their account, and admins can inspect and manage the server).

To keep up to date with developments, follow this blog, or our accounts on Mastodon or Twitter!

Snikket Blog on Snikket Chat

Snikket Server - September 2024 release

What’s new

Invitations

Changes to blocking

Technical stuff

Other

Upgrading

Snikket Server - July 2024 release

What’s new in this release?

Web portal

Role selection

Comments

Sharing

New setup guidance

Privacy and security

For admins

Translations

Everything else

Snikket Android app temporarily unavailable in Google Play store [RESOLVED]

Summary

Workaround for Android users

The full story

It all began when…

Wait, a messaging app that can’t send messages?

The removal

This is an unsustainable situation

Security notice: Snikket not affected by CVE-2024-3094

Snikket server

Snikket Hosting

More information

Snikket Hosting is now available!

🪙 Pricing

🦸 Beta users

☎️ JMP partnership

💬 Support and feedback

❤️ Thanks

😺 Curious to try out Snikket?

Snikket Server - January 2024 release

What’s new in this release?

Changes to Circles

Last activity display

Connectivity and security

Faster and stronger authentication

Dropping older security protocols

Easy account restoration

Farewell to the welcome message

Languages and translations

Other changes

Installing and upgrading

On the jabber.ru MITM attack

What happened with jabber.ru?

Why is this news?

How is this related to Snikket?

Custom domains with Snikket

Custom domains on our hosting platform

Self-hosted instances

State of Snikket 2023: Funding

State of Snikket 2023: The Apps

UI/UX

iOS

Android

The future of building Snikket apps

State of Snikket 2023

F-Droid security update

Notes on the F-Droid security warning

How F-Droid works

WebRTC woes

What can you do?

Conclusion

Server updates for ARM systems

Web interface ARM compatibility

Compatibility with Debian 10

January 2022 server release

Account import and export

Improved resource monitoring

Internal changes

Installing or upgrading

Snikket Server - 2022-01-13 security release

Snikket Server - 2022-01-13 security release