This article was written by Reem Almasri and Rima Sghaier, independent members of MADR

In early 2026, the MENA Alliance for Digital Rights (MADR) community agreed on the pressing need to adopt a new internal communication tool to serve its expanding membership, the formation of sub-committees, and emerging collaborations. Signal had served us well in MADR’s early years as a secure tool for sharing updates, but it was time to move to something that offered multi-channel support and more organized collaborative workflows. Just as with Signal, we agreed that any new tool had to align with MADR’s responsible tech values, prioritizing Free/Libre and Open Source Software (FLOSS), strong encryption, usability and accessibility and, where possible, autonomous governance. We drew inspiration here from the Association for Progressive Communications (APC), whose thirty years of working online for social change affirm “the importance of steering away from technological fads and focusing instead on the functionality of the tools themselves.”

Community members offered plenty of suggestions based on tools they’d used in other networks or ones they had been interested in adopting: DeltaChat, Element, Mattermost, Quiet, Rocket.Chat, SimpleX Chat and Zulip. Rather than rely on anecdotal feedback alone, we turned this into an exploratory community research project: our members’ actual needs shaped the process of selecting which open-source communication tools to evaluate and compare.

We, two independent members of the MADR community, led the effort, forming a research and user testing committee to gather diverse experiences and threat models from members across different countries in the region and in diaspora, spanning different devices, operating systems, and network conditions.

Our starting point was MADR’s concrete needs: arranging, tracing, and archiving weekly and monthly communications; creating multiple channels, and accounting for the varied threat models of members with different levels of exposure to surveillance, censorship, internet disruptions, and device seizures. These needs guided an agreed-upon list of non-negotiable and negotiable features.

The Non-Negotiables

Any tool we adopt must support Arabic language use. This includes proper right-to-left (RTL) and bidirectional (BiDi) rendering so that messages combining Arabic and English are displayed correctly. We need flexible multi-channel capability, file-sharing and direct messaging with a genuinely user-friendly mobile app. Our members use multiple devices and work asynchronously, so the desktop and mobile experiences need to be equally responsive and intuitive.
Given that some MADR members face serious security risks including device seizure, we require strong operational security (OpSec) features including strong encryption in transit and at rest (ideally end-to-end encryption), mobile app locks, disappearing messages, the option to self-host, and remote account wipe capabilities.
The software must be reliable and actively maintained. We’ll evaluate this through the frequency of software and security updates, and importantly, through the availability of independent security audits.
Finally, familiarity, ease of adoption, and accessible and inclusive design are key, ideally a tool with a UX experience similar to what members are accustomed to (which we assessed through a survey), or at minimum one with a low learning curve.

The Negotiables

Resilience during internet shutdowns isn’t critical for the coalition’s primary internal communication platform as MADR isn’t a local network with constant daily communication needs. 

Client-level backups matter less when we’re self-hosting, as long as the infrastructure provider maintains regular server backups and has clear recovery procedures in place. 

Integration with other apps such as video conferencing and project management platforms could be convenient but it is not a critical feature in this context. 

Some other features are simply nice-to-have: voice notes, contact sharing, and built-in GIF and emoji support. Most modern platforms offer these anyway, though we’ll admit, even 90s-style text emoticons could still capture our feelings. ¯(ツ)/¯

The Verdict for Now: A Self-Hosted Path Forward

We initially dismissed Mattermost for lacking built-in end-to-end encryption and leaned toward prioritizing E2EE, since many members cared not just about protecting their data from third-party adversaries, but also about knowing their conversations were private even from the system administrators running the server. However, the E2EE-first alternatives we explored (Delta Chat, Element, Quiet, RocketChat, and SimpleX Chat) showed either one or more of the following shortcomings relative to our functional needs:

• Lack of Arabic language and right-to-left support
• Mixed-language rendering issues in replies
• Unstable software with inconsistent maintenance
• Lack of stable, functional mobile versions
• Lack of independent security audits and transparency
• Advanced security features and permissions management restricted to paid Enterprise tier (“open core” model)
• Steep adoption learning curve for our community

Given these gaps, we agreed on renegotiating the non-negotiable features taking into consideration the members feedback on functionality and design trade-off and shifting to prioritizing multi-channel support, easily searchable message archives and ended up shortlisting Mattermost, Zulip, and Element. We raised concerns that Mattermost and Zulip don’t offer built-in end-to-end encryption. Element did offer E2EE, but the learning curve around managing security keys, combined with poor rendering of mixed Arabic/English text, discouraged many members from choosing it.

Zulip’s topic-based conversation structure and multi-column layout differ fundamentally from Slack/Mattermost’s linear channel-based design, requiring users to mentally reorganize how conversations flow. So between Zulip and Mattermost, the coalition chose the tool more members were comfortable with, Mattermost, to lower the barrier to adoption.

According to coalition member and information security expert Ragheb Ghandour, many of our concerns around the lack of native end-to-end encryption are less relevant in the context of self-hosting. It’s worth remembering that metadata can leak even on platforms that do offer E2EE. According to Ghandour, a self-hosted Mattermost instance keeps encryption keys, message content, metadata, and access logs entirely within our own infrastructure, so no third party can be compelled to disclose them. The key is to keep Mattermost regularly updated to patch known vulnerabilities, monitor and secure network access to the instance, and apply security patches promptly. Self-hosting also gives us direct access to audit logs, so we can see exactly what’s being accessed.

Tools are only as secure as the environments hosting them. Mattermost has published a Zero Trust checklist to help enforce security controls across multiple layers. Announcing E2EE support isn’t meaningful without a third-party security audit and published findings, as with the E2EE plugin (which hasn’t been updated since 2023) developed for Mattermost via web client, by French cybersecurity company, Quarkslab.

Takeaways and Lessons Learnt

This effort isn’t meant as a comprehensive evaluation or comparison of open-source communication apps, but rather a record of the collective process of choosing a tool centered on our community’s needs. Many of the apps we tested had real strengths suited to specific security contexts. SimpleX Chat offers a high level of security and privacy as it has no identifiers assigned to users. DeltaChat‘s use of the email protocol makes it highly resilient to censorship and internet shutdowns. Quiet syncs messages directly between a team’s devices over Tor, with no server required. Element‘s federation and interoperability capabilities enable decentralized communication. And Zulip is maintained by the Zulip Foundation, a nonprofit with governance similar to Signal’s, which helps ensure long-term independence and sustainability.

Mattermost has its shortcomings too. But weighing our values against our subjective practical needs as an alliance, and against the real challenge of secure communication, made it the most suitable for us.

Choosing an internal communications app was, in many ways, the low-hanging fruit in our broader journey toward digital resilience. Still, it raised questions we’ll need to revisit when adopting larger autonomous infrastructure, like internal storage platforms (NextCloud) or alternative social platforms (the Fediverse). A few reflections from the process:

• Stay open-minded, especially when balancing high security features against functionality. What feels non-negotiable can become negotiable depending on the hosting environment. What we initially missed in treating E2EE as non-negotiable was the human trust factor, the trust members place in the admins and the hosting organization. When we first framed E2EE as essential, we were guarding against administrators accessing data on a self-hosted instance. But this tool isn’t a daily communication app nor meant for highly-sensitive information; it’s an organizational tool for our weekly and monthly collaborative work. The final consensus on Mattermost reflected the trust members had already built with the hosting entities within our community.
• Engaging the community in testing and choosing a technical tool is a long process, but a meaningful and essential one. It signals to your members that their experiences and concerns matter, not just for outcomes but also for how decisions get made. It also reduces resistance and troubleshooting down the line.
• The journey towards digital resilience is collective, not individual. Sharing an autonomous platform means sharing its governance and sustainability too. One organization in the alliance stepped up to self-host Mattermost on its own servers (the maintenance costs were manageable), while another member agreed to administer and maintain the instance. This exercise raised important questions for future more complex transitions, to cloud storage or a self-hosted Fediverse instance, for example: what processes do we need to set up collectively to govern and share autonomous infrastructure? How can we pool technical and human resources to sustain that autonomy?

Choosing an open-source, self-hosted communication platform is only the beginning. Our alliance recognizes how little documentation and peer-learning exist for social justice organizations starting their journey toward autonomous infrastructure and independence from Big Tech. So we decided to turn this effort, selecting a tool, into something bigger: documenting a community-centered process for assessing internal infrastructure, and offering alliance members peer-to-peer learning opportunities to actually administer these self-hosted applications.

We’d also love to hear from other human rights coalitions, networks, and communities: what processes have you used to move toward autonomous, self-hosted infrastructure for your own operations?