= = = serverless = = =

- Reading time: 17 minutes / whole rubric: 23 minutes -


  • Server-based Messengersystems (“condition”) need appropriate servers for usage - e.g. for contact list, message forwarding, groups or chat room management.
  • Server-supported Messengersystems (“possibility”) basically work without special (additional) servers - however, servers can be used for special functions (like buffering of messages).
  • Serverless Messenger systems (“abandonment”) are completely decentralized and organized without special (additional) servers.

In addition to the systems listed in system comparison, there are many other interesting projects, a few of which are listed here. Even though little information has been collected on some of these, they should not be neglected.

Again and again “P2P” and “anonymous” will jump in the eye in the following - in addition the following explanations: P2P / Anonymity.

In general:

  1. Mesh/P2P systems can usually be used without costs (don’t forget donations/development orders!).
  2. battery consumption on mobile devices is higher than with server-based systems
  3. multi-device capability is extremely difficult to realize in P2P systems without additional servers as intermediate stations
  4. delivery of offline messages is not possible without an additional intermediate station (“mailbox”)

In the following overview, a German website is rated as positive and a lack of German-language information as negative. Why? It would be arrogant to assume that “everyone” understands English or even to demand basic knowledge. Information should be understood by every native speaker and unnecessary misunderstandings due to insufficient translations should be avoided. Good translations make a product in general (here: Messenger) interesting and accessible to the masses, because you save many interested people/users unnecessary translation effort. They are enormously helpful and therefore worth their weight in gold.


Also “serverless” are LAN messenger, but they cover a completely different use case.


Regardless of the solution used, the app “Oversec” can also be used on Android devices. This app virtually overlays others and encrypts/decrypts inputs before they are in the actual messenger. Sounds crazy, but it’s not and works great. So security-minded people should definitely take a look at this app!

Download: at F-Droid (external) or directly as APK: https://www.oversec.io/#download (external)
Project page: https://www.oversec.io (external)
Note: Oversec is probably not actively developed anymore since 2019 / it does not respond to Github-issues anymore.

Anonymous Messenger

  • decentralization: direct, uses TOR (P2P, no separate servers)
  • positive: some anonymity
  • positive: uses Signal protocol for encryption
  • negative: the protocol (external) is not yet properly documented!
  • negative: only available for Android
  • negative: NO german project page

Source code: https://git.anonymousmessenger.ly/dx/AnonymousMessenger (external)
Project page: https://anonymousmessenger.ly (external)


pyBitmessage (Bitmessage)

Sends to ALL participants, only the recipient can decrypt and read message (no sender/recipient address).

  • decentralization: direct/mesh (P2P, no separate servers).
  • positive: some anonymity
  • negative: NO German project page/help
  • negative: ONLY usable on PC/laptop - NOT on smartphones

Source code: https://github.com/Bitmessage/PyBitmessage (external)\
Project page: https://bitmessage.org/wiki/Main_Page (external)


  • decentralization: direct, uses TOR (P2P, no separate servers)
  • positive: some anonymity
  • negative: NO german project page

More information: >> here <<


Databag is a self-hosted messenger (and should actually be listed under server-based messenger systems).

  • Decentralization: Databag has its “own” definition of P2P
  • positive: certain anonymity
  • positive: very low resource requirements
  • positive: clients for Android, iOS and browsers
  • negative: NO German project page
  • negative: there is no technical description / whitepaper yet (corresponding documentation and tutorials are planned)
  • negative: only one developer is currently managing the project

With its extensive range of functions and focus on data protection and security, the aim is to offer a comprehensive and reliable self-hosted messaging solution. Databag’s ultimate goal is to also be embedded/used in low-cost electronics to reach a much broader, less technical audience. Currently, the network node runs well on a Raspberry Pi Zero v1.3. as extremely few resources are required. Key features include:

  • Decentralized (direct communication between app and server node)
  • Federated (accounts on different nodes can communicate)
  • Public and private key based identity (not tied to a blockchain or hosting domain)
  • End-to-end encryption (hosting administrator cannot view sealed threads, unsealed by default)
  • Audio and video calls (nat traversal requires separate relay server)
  • Topic-based threads (messages are organized by topic and not by contact)
  • Lightweight (server can run on a Raspberry Pi Zero v1.3)
  • Low latency (use of websockets for push events to avoid polling)
  • Unlimited number of accounts per node (host for the whole family)
  • Mobile notifications for new contacts, messages and calls (supports UnifiedPush, FCM, APN)

The messenger can even be tested in a test instance (external). But please do not post anything important, as the server is deleted regularly.

Information directly from the developer:

Coupled with the resource requirements is efficiency and fast client synchronization. The user does not have to wait for the client to pick up all conversations when the app is first started or when it is restarted after a long period of time. The data model for Databag is very simple and you know where your data is. The data is only located on the node of the account for the conversation and the designated client devices.

The Databag node (protocol/API) is abstract and does not focus primarily on message exchange, but simply on data sharing. The Databag network is open, and I have several other applications I want to write for the network (notably decentralized ratings and file sharing by trusted contacts).

Technical details: End-to-end encryption is implemented with RSA and AES. The synchronization data is transmitted as a body of HTTP messages.

Source for information: medevel.com (external)
Source code: github (external)


Name development: “SFLphone” -> “Ring” -> “Jami”.

Originally developed for telephony (audio / audio and video / audio and video in groups, depending on the operating system), but text messaging is also possible; text-based chat rooms are being worked on.

Jami enables secure text, voice and video communication over the Internet. It also allows teleconferencing and videoconferencing, but strangely no text-based chatrooms yet, as the developers are trying to make these fully decentralized. Jami is a good choice for secure phone calls over the Internet, as long as the people on the call are also using Jami. Jami is a peer-to-peer system; it does not rely on or require central servers.

Jami is cross-platform, with versions for Android, FreeBSD, iOS, iPhone, Linux, Microsoft Windows, and OS X. There is (as of March 2020) no version for the Pinephone.

It is both a peer-to-peer voice-over-IP client program and a custom protocol for service discovery using a distributed hash table (DHT). It uses SRTP to transfer communication data.

P2P with server?

We keep saying that Jami’s most distinctive and innovative characteristic is the fact that it doesn’t require a server to relay data between users. There are many advantages associated with that, including increased privacy, light infrastructure, high scalability, no bandwidth restriction (other than that of your Internet connection), no size limit for file transfers, and more. This is all true, but while servers are not required, they are still used in five specific cases: push notifications, the OpenDHT proxy, bootstrap, name server, and TURN. … >> more << (external)

Description: https://linuxreviews.org/Jami (external; English)
Security questions and answers from a developer: stackexchange.com (external)
Using GIT for messages (‘swarm’): jami.net (external; english)
Also available via F-Droid and thus without tracker: https://f-droid.org/en/packages/cx.ring (external)

  • Decentrality: direct (P2P with support of separate servers)
  • positive: some anonymity
  • negative: The project page also integrates third party services (transifex): webbkoll (external)
  • negative: NO german project page

Source code: https://jami.net/contribute/ (external)
Project page: http://jami.net (external)


Traffic analysis resistant messaging - We write mix network protocol libraries. What is a mix network? It is an anonymous communications system… however the word anonymous is problematic because some government authorities equate anonymity with terrorism. We prefer to instead call it “network security” because you can feel more secure when you communicate using traffic analysis resistant communications protocols. …

This project has received funding from the “European Union’s Horizon 2020 research” and innovation programme”, the “Samsung Next Stack Zero grant” and “NLnet and the NGI0 PET Fund paid for by the European Commission”.

  • decentralization: direct/mesh (P2P, no separate servers).
  • positive: some anonymity

Source code: https://github.com/katzenpost (external)
Project page: https://katzenpost.mixnetworks.org (external; Englisch)


  • decentralization: direct/mesh (P2P, no separate servers)
  • positive: some anonymity
  • negative: NO german project page/help

Source and project page: https://github.com/neuravion/mesh-chat-protocol (external; englisch)


A messaging platform that uses Tor and IPFS and sees itself as an alternative to Slack and Discord.

  • Decentralized: direct, uses TOR (P2P, no separate servers)
  • positive: certain anonymity
  • positive: concrete threat model (”threat-model” (external)) is described
  • negative: NO German project page/help

Each group, referred to as a “community” in Quiet, works in its own network. This guarantees that the data of a community remains completely isolated from the devices of other Quiet users, even if it is encrypted.

The synchronization of messages is seamlessly facilitated by OrbitDB, which combines the features of Git, a Gossip protocol, and BitTorrent. It efficiently sends new messages, synchronizes recent messages and retrieves files. As a result, users can expect to receive all messages that were sent while they were offline.

Invitations, access permissions and usernames are assigned exclusively by the owner of the community, who takes responsibility for creating the community.

The owner provides an exclusive “invite code” that allows invitees to connect to their device, register a username and purchase a standard cryptographic certificate to confirm their membership to other peers within the community.

This is how Quiet sees itself compared to Slack, Discord, Signal, Matrix, Session, Briar, Cwtch, Cabal and Ricochet Refresh: https://medevel.com/quiet (external)

Source for information: https://medevel.com/quiet (external)
Source code: https://github.com/TryQuiet/quiet (external)
Project page: https://tryquiet.org (external)


Extreme privacy is much more difficult to achieve than security. Reticulum seems to do this very well because it is not based on the Internet Protocol (IP). With the Internet Protocol, a source and destination address is always known (IP addresses). Even Tor (the onion routing) or VPN (virtual private networks) are also based on IP. In contrast, the Reticulum network system does not know the source but only the destination.

  • Decentralization: direct, IP-independent (P2P, no separate server required)
  • positive: very good anonymity / very “secure”
  • negative: Reticulum is still in the beta stage and is experimental software (June 2024)
  • negative: Not suitable for corporate use, as only encrypted communication is possible.

The “Lightweight Extensible Message Format” (LXMF) protocol, which is a distributed, delay- and interruption-tolerant message transmission protocol, is based on Reticulum. LXMF is a simple and flexible message format and transmission protocol that allows for a variety of implementations while using as little bandwidth as possible. The protocol offers zero-conf message routing, end-to-end encryption, forward secrecy and can be transported over any medium supported by Reticulum.

LXMF is so efficient that it can transmit messages over extremely low bandwidth systems such as Packet Radio or LoRa. Encrypted LXMF messages can also be encoded as QR codes or text-based URIs, enabling completely analog message transport on paper.

The target group is, for example, emergency services in disaster areas.


  • Nomad Network
    A network-independent, encrypted and resilient mesh communication platform.
  • Sideband
    The Android, Linux and macOS application has a graphical interface and focuses on ease of use.


Reticulum can be used over virtually any medium that supports at least a half-duplex channel with a throughput of 500 bits per second and an MTU of 500 bytes. Data radios, modems, LoRa radios, serial lines, AX.25 TNCs, digital ham radio modes, WiFi and Ethernet devices, free space optical links and similar systems are examples of physical devices that Reticulum can use. Supported interface types include:

  • Any ethernet device
  • Almost all WiFi-based hardware
  • LoRa using RNode
  • Packet Radio TNCs (with or without AX.25)
  • KISS-compatible hardware and software modems
  • Any device with a serial port
  • TCP over IP networks
  • UDP over IP networks
  • External programs via stdio or pipes
  • Custom hardware via stdio or pipes

For example, it is possible to connect a Raspberry Pi to a LoRa radio as well as to a packet radio TNC and a WiFi network. Once the interfaces are configured, Reticulum takes care of the rest, and any device on the WiFi network can communicate with nodes on the LoRa and packet radio side of the network and vice versa.

Source and project page: https://reticulum.network/index_de.html (external)


  • decentralization: direct/mesh, uses TOR (P2P, no separate servers)
  • positive: some anonymity
  • negative: NO German project page

Documentation: https://retrosharedocs.readthedocs.io/en/latest/ (external; english)
Source code: https://github.com/RetroShare (external)
Project page: https://retroshare.cc (external; english)

Ricochet Refresh

Ricochet Refresh is a maintained and up-to-date fork of the former Ricochet project.

  • decentralization: direct, uses TOR (P2P, no separate servers)
  • positive: some anonymity
  • negative: NO German project page/help

Source code: https://github.com/blueprint-freespeech/ricochet-refresh (external)
Project page: https://www.ricochetrefresh.net (external)


Federated via TC providers and works on the basis of SMS.

  • decentralization: direct (P2P, no separate servers required)
  • negative: mobile number required (SMS sending/receiving)
  • negative: Messenger only for Android

Source code: https://git.silence.dev/Silence/Silence-Android/ (external)
Project page: https://silence.im (external)

TinfoilChat (TFC)

If you think you are really being targeted by secret services, you should take a look at the hardware-supported chat solution TinfoilChat (TFC). They seem to be serious and this is one step more “extreme” than e.g. Briar:

Tinfoil Chat (TFC) is a FOSS+FHD peer-to-peer messaging system based on a highly secure hardware architecture to protect users from passive collection, MITM attacks, and most importantly remote key exfiltration. TFC is designed for people with one of the most complex threat models: organized criminal groups and government hackers who bypass the end-to-end encryption of traditional secure messaging apps by hacking the endpoint.

  • decentralized: direct, uses TOR (P2P, no separate servers required)
  • positive: best possible anonymity / extremely “secure”
  • negative: separate hardware required
  • negative: NO german project page/help

Source and project page: https://github.com/maqp/tfc/ (external; unfortunately only english; really exciting to read!)


Audio and video calls are possible and there are different clients with graphical as well as text-only user interface.

  • decentralization: direct, also via TOR (P2P, no separate server required)
  • positive: some anonymity
  • negative: Note at the project page (download section): “Tox is still under heavy development — expect to run into some bugs”
  • negative: NO German project page

Field report: https://herrdoering.de/de/sicheres-messenging-mit-tox-chat/ (external)
Usage with TOR: https://wiki.tox.chat/users/tox_over_tor_tot (external)
Raspberry Pi for offline messages (external; english)
Possible clients: qTox, uTox, Toxygen, Toxic, aTox (external), Trifa (external)
Client functions: https://wiki.tox.chat/clients#features (external)
Source and project page: https://tox.chat (external)


Also an interesting project - but currently no active further development anymore (last change to the source code was in September 2019).

  • decentralization: direct (P2P, different servers)
  • positive: some anonymity
  • positive: wants to obfuscate unnecessary metadata
  • negative: concept only, no changes to source code since 2019
  • negative: NO german project page/help

Interview with one of the developers: netzpolitik.org
Source code: https://github.com/vuvuzela/vuvuzela (external)
Project page: https://vuvuzela.io (external, unfortunately only English)