Feature | aTalk | Briar | Cheogram | Conversations | cwtch | Delta.Chat | Dino | FluffyChat | Gajim | GNUnet Messenger-GTK | Apple iMessage | Jami | keet | Keybase | Manyverse | Matrix Element | Meshenger | Molly | Monal | monocles chat | Mumble | NekoX | Nheko | Olvid | OnionShare | Pidgin | PyBitmessage | qaul | Quassel | quiet | RetroShare | SafeUM | SchildiChat | Session | Sideband | Signal | Signal-FOSS | Signal-JW | SimpleX Chat | Skype | smoke | Snapchat | Telegram | Telegram FOSS | Teleguard | Threema | Tox | Viber | Wickr | XMPP | Elixxir xx | wire | Zoom | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Availability | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
AnalysisTextual review that can not be compared objectively through properties | #briar_review | #cwtch_review | #delta_chat_review | #imessage_review | #jami_review | #matrix_review | #olvid_review | #session_review | #signal_review | #simplex_review | #skype_review | #snapchat_review | #telegram_review | #teleguard_review | #threema_review | #tox_review | #whatsapp_review | #xmpp_review | #wire_review | #zoom_review | ||||||||||||||||||||||||||||||||||
SummaryHighlight in a few words why it is interesting | XMPP video calls and GPS for Android | P2P chat over LAN, BT and Tor | Conversations fork with SIPTo implement features of use to the Sopranica project | XMPP video calls for Android | Persistent messenger over Tordecentralized, privacy-preserving, multi-party messaging protocol that can be used to build metadata resistant applications | Group chat over email, user apps | XMPP video calls for desktop | Playful design for Matrix | XMPP chat for desktopWith LAN-mode | GNUnet Messenger service, GTKEarly alpha. Provide private and secure communication between any group of devices. | Default on Apple platforms | P2P chat, video calls and SIPDecentralized chat, voice calls, videoconferencing and SIP client | P2P chat, video calls and file sharing | Chat, files and identity proofE2EE chat, storage, file sharing and git repositories, can connect with communities from Twitter, Reddit, and elsewhere for account verification | P2P social network on LAN/WANP2P social network over LAN or WAN with everything stored on your device, for desktop and mobile | Extensible protocol to bridge allAssume using Matrix Synapse as server, Element matrix client | P2P video calls for LANP2P Voice/Video phone App over local networks | Fork of Signal with hardening | XMPP for iOS | blabber.im (Conversations) forkTo improve privacy an usability | Quality group calls with low latency | Polished Telegram FOSS forkSoft fork with proxies, options, actions, ergonomy, formerly Nekogram X | Native desktop Matrix appC++20 and Qt, to compete with mainstream proprietary messengers w | Chat over untrusted serverno centralized user directory w | Multi-account, multi-protocol pluginsUniversal chat client which lets you log into accounts on multiple chat networks simultaneously. Common choice for XMMP, with LAN-mode. w | Internet Independent Wireless Mesh Communication App w w | IRC client and bouncerModern, cross-platform, distributed IRC client with local server backend w | P2P team chat on TorAlternative to team chats, all data syncs directly between a team's devices over Tor with no server required w | F2F social network, P2P on Torcross-platform, Friend-2-Friend and secure decentralised communication platform w | Chat and calls on AndroidSecure Multimedia Messenger | Chat, video calls by phone number w | Libre Signal fork, no blobsSoft fork of Signal for Android with proprietary Google binary blobs removed, uses OpenStreetMap for maps and a websocket server connection w | Signal fork with more optionsSignal for Android with additional options and small customization features w | Uses relays, protects metadata, no user profile IDs (not even random)Decentralized end-to-end encrypted messenger focusing on meta-data protection and avoiding any user profile identifiers w | Chat and video calls, landlineChat, voice and video calling app with opt-in E2EE owned by Microsoft w Paid calls to landline and cellular numbers are a possible option | Expiring chat and photosAmerican photo messaging application w | Chat, calls and blogChat, calls and in-app blogging platform with opt-in E2EE w Client is open source, server is not. E2E encryption isn't enabled by default | Libre Telegram fork, no blobsFOSS-friendly soft fork of Telegram Android w | Paid, anonymous, for home or workPaid and proprietary end-to-end encrypted instant messaging service. w | P2P random ID over DHTNameless DHT messenger w | Chat and video calls, landlineProprietary, option for paid landline and cellular calls via Viber Out w | Chat, video calls by phone numberPopular messaging app by Meta/Facebook w | Features as spec extensionsCommunication protocol that multiple clients use in this chart. w | Paid chat on blockchainMessaging app powered by the quantum-resistant and decentralized xx network w | Chat, video calls for workE2EE cross-platform chat, voice and video calls messenger with an option to register w/o phone number. Also optional paid tiers w | Freemium video calls w | ||||||||
ScreenshotsList URLs in the details (TODO: gallery widget) | w | w | w w w | w w w w | w w | w | w | w | w | |||||||||||||||||||||||||||||||||||||||||||||
Android Google Play | yes w | yes w | no w | paid w | currently in testing w w | yes w | no | yes w | no | no | no | yes w | not full featured w w | yes w w | yes w | yes w w | yes w | no | no w | nonone uploaded, but source code contains mentions | 3rd party w | no | no | yes w | only client via Tor BrowserJavaScript required | no | no w | yes w | yes w | yes w | no | yes w | yes w | yes w | no | yes w w | no | no | yes w | yes w | no | yes w | yes w | no | yes w | yes w | yes w | yesw | yesw | yes w | yes w | yes w | ||
Google Play version(automatically generated release and Android API version) | 2024-05-16: 4.1.0 33.0MB (Android 7.0+) | 2024-05-10: 1.5.11 56.4MB (Android 5.0+) | 2024-06-04: 2.15.3+playstore ? (Android 6.0+) | 2024-06-10: 1.46.2 56.0MB (Android 4.1+) | 2024-06-03: 1.21.0 82.7MB (Android 5.0+) | 2024-06-01: 20240529-01 91.9MB (Android 7.0+) | 2024-06-04: 3.3.1 96.9MB (Android 7.0+) | 2024-05-30: 6.3.1 151.3MB (Android 5.0+) | 2023-10-10: 0.2310.9-beta-googlePlay 49.4MB (Android 5.0+) | 2024-04-08: 1.6.14 72.1MB (Android 5.0+) | 2024-02-10: 4.2.7 8.4MB (Android 4.4+) | 2024-04-04: 3.6.10 6.3MB (Android 4.0+) | 2024-06-10: 2.2.1 85.2MB (Android 5.0+) | 2024-05-10: 2.0.0-beta.18 33.3MB (Android 8.0+) | 2024-05-08: 1.6.2-33-ge4e3abb5 4.3MB (Android 5.0+) | 2024-04-10: 2.1.2 38.0MB (Android 8.0+) | 2024-03-22: 1.1.0.1640 33.3MB (Android 5.0+) | 2024-06-05: 1.6.16.sc78 151.9MB (Android 5.0+) | 2024-05-31: 1.18.4 97.4MB (Android 6.0+) | 2024-06-03: 7.8.1 61.5MB (Android 5.0+) | 2024-06-05: 5.8 99.3MB (Android 8.0+) | 2024-05-30: 8.120.0.207 71.0MB (Android 8.0+) | 2024-06-10: 12.90.0.46 146.9MB (Android 5.0+) | 2024-06-07: 10.13.4 132.4MB (Android 6.0+) | 2024-05-06: 5.3.1 ? (Android 5.0+) | 2022-02-23: 0.7.3 14.4MB (Android 4.4+) | 2024-05-31: 22.8.0.0 173.2MB (Android 5.0+) | 2024-06-12: 2.24.13.5 54.8MB (Android 5.0+) | 2023-02-03: 6.2.7 43.2MB (Android 8.0+) | 2022-08-26: 2.92 48.5MB (Android 8.0+) | 2024-05-31: 4.7.1(9803154)-prod 118.5MB (Android 8.0+) | 2024-06-04: 6.0.12.22225 184.6MB (Android 6.0+) | ||||||||||||||||||||||
Android F-droid/apkyes=f-droid.org, partial=apk or separate repository | yes w | yes w w w | yes w | yes w | apk w w | F-droid w apk w | no | yes w | no | no | no | yes w | no w | no | yes w w | yes w | yes w | partial w | no w | yes w w | 3rd party w | yes w | no | no wdiscussing it | only client via Tor BrowserJavaScript required | no | apk w | yes w | not anymoreold package removed, libretroshare for android is still maintained w | yes w w | yes w w w | apk w | repo w apk w | apk w | yes w w w | no | yes w | no | no | yes w | yes w w | no w | partial wsee "Package installer" | noNeither can an apk be dowloaded from their site, as they link directly to Google Play | apk yes, F-droid no.the apk is a bit hard to find on the website. look for "android source code" section, there it is. | yes w | ||||||||
F-droid version(automatically generated release and Android API version) | 2024-05-17: 4.1.0 64MiB (Android 7.0+) | 2024-05-17: 1.5.11 56MiB (Android 5.0+) | 2024-05-30: 2.15.3-1+free 27MiB (Android 6.0+) | 2024-06-09: 2.16.4+free 26MiB (Android 6.0+) | 2024-03-16: 1.44.0 28MiB (Android 4.1+) | 2024-06-05: 1.21.0 84MiB (Android 5.0+) | 2024-06-02: 20240529-01 91MiB (Android 7.0+) | 2023-02-06: 0.2302.2-beta-fdroid 45MiB (Android 5.0+) | 2024-05-03: 1.6.14 74MiB (Android 5.0+) | 2024-05-09: 4.2.8 19MiB (Android 4.4+) | 2024-05-09: 1.7.9.6 45MiB (Android 6.0+) | 2024-04-09: 3.6.10 8.6MiB (Android 4.0+) | 2023-10-04: 9.3.3 74MiB (Android 4.4+) | 2022-03-14: 1.6.2 4.6MiB (Android 5.0+) | 2024-06-09: 1.6.16.sc78 76MiB (Android 5.0+) | 2024-06-05: 1.18.4 107MiB (Android 6.0+) | 2024-06-09: 5.8 61MiB (Android 8.0+) | 2024-01-07: 2024.01.05 3.9MiB (Android 7.1+) | 2024-05-22: 10.12.0 78MiB (Android 4.4+) | 2024-05-17: 5.3.1l 109MiB (Android 5.0+) | 2024-05-17: 1.0.231 59MiB (Android 5.0+) | 2022-09-02: 3.82.38 35MiB (Android 7.0+) | ||||||||||||||||||||||||||||||||
Other mobileAlternative phones like KaiStore, Blackberry, OpenStore, PureOS, Microsoft Store | no | no w | no | no w | KaiOS unsupported w | no | no | no w | no w | no | no | |||||||||||||||||||||||||||||||||||||||||||
Other AndroidAlternative app stores like Amazon Appstore, Huawei App Gallery, Samsung Galaxy Store, Opera Mobile Store, Aptoide, GetJar, Uptodown, Applivery | yes w w w | no | no w | yes w | not yet w | partial w w | IzzySoft w | yes | Huawei w | |||||||||||||||||||||||||||||||||||||||||||||
Apple iOS | no | no w w | no | no | not yet available w w | yes w | no | yes w | no | no | yes | yes w | not full featured w w | yes w | yes w w | no w | no | no | unmaintained since 2017 w | no | no | only client via Tor BrowserJavaScript required | no | no w | TestFlight w | yes w | not yet w | partial w w | no | yes w | no | no | no | yes w | yes w | yes w | yes w | no | yes | no w | yes w | yesw | yesw | yes w | yes w w w | |||||||||
Desktop | no | no | no | Linux, Windows, MacOS w w | macOS, Windows, LinuxMac App Store, dmg, Homebrew, Microsoft store, exe, flathub, deb, rpm, AppImage, tar.gz, AUR, Nix w | yes w w | Windows, MacOS, Linux, FreeBSD Ports w | Flatpak w or source w w | Included in MacOSNot downloadable or available on other platforms | yes w w | macOS Linux Windows w w | macOS w Windows w Linux w | yes w w w | no | no | no | Linux, Windows, MacOS w w w | no | yes w | FreeBSD/Linux/macOS/Win w | yes w | yes w | Linux, Mac, Windows w | Windows, MacOS, Linux, FreeBSD Ports w | yes w | Linux and Windows w | Linux, Windows and macOS w | as secondary device w w w | no | no | yes w | no | yes w | no | only if mobile online | only a remote/syncNo full or partial desktop client, app is phone centric | yesw | Linux, MacOS, Windowsw | no w | yes w w | ||||||||||||||
Web | no | noOnly app, no web client | no | no | no | no w | no | yes w | no | no | no | no w | no w w | some account functionality and encrypting/decrypting messagesAccount changes can be locked to be only possible through client apps w | yes w | no | no | no w | yes w | no | no | only client via Tor BrowserJavaScript required | no | no w w | no | partial w w | yes w | no | no | no | no | no | no | yes w | coming soon to web w | yes w | no | only if mobile online | no w | no | yesweb.whatsapp.com | no | no w | |||||||||||
LanguagesThe higher the amount of people reachable the better. No=1 language, partial=2-3, yes=many global ones | 7 w | many w | 34 w | 54 (21 full) w | 14 w | 14-48 w w w | 39 w29 full, 4 medium, 6 some | 12+ w | 37 w4 full, 4 medium, 29 some | English | many w w | English, Spanish, Russian w | English only | many w w | 7 w | 70+ w | 10English Basque Chinese French German Italian Polish Spanish Turkish Ukranian w | 31 w | 46 w | 24 w | many w | 105 w | 13 w | many w | many w | 100+ w w w | 100+ w | 100+ w | 12-14English Chinese Czech Dutch French German Italian Japanese Polish Portuguese Russian Spanish w | many w | many w | many w | many w | 16 w | yes | 1 w | ||||||||||||||||||
Protocol | Jabber/XMPP | Bramble (aka BTP) | Jabber/XMPP | Jabber/XMPP | w | SMTP and IMAP with AutoCrypt w | Jabber/XMPP | Matrix | Jabber/XMPP | GNUnet w | iMessage | SIP, OpenDHT w | Keet, Pear | SaltPack, NaCl + MessagePack w | Matrix | WebRTC w | Signal Protocol w | Jabber/XMPP | Mumble w | MTProto w | Matrix | unnamedBuilt on top of Tor | Jabber/XMPP, multipleBonjour, Gadu-Gadu, IRC, Novell GroupWise Messenger, Lotus Sametime, SILC, SIMPLE, Zephyr + extendable via plugins w | BitMessage w | Noise Protocol w w | IRC | Matrix | Session protocol, fork of Signal protocol w | Signal Protocol w | Signal Protocol w | Signal Protocol w | SMP, Signal Protocol w | proprietary w | Echo w | MTProto w | MTProto w | Tox protocol w | homebrewViber's security protocol was based on the "double ratchet" protocol found in Open Whisper Systems Signal application, with our own proprietary implementation and additions. Our entire security overview is available here. w | signal protocol w | Wickr Secure Messaging Protocol (Home browed) | XMPP | blockchain and mixnetxx blockchain coin based on Praxxis with xx cMix mixnet privacy layer | ||||||||||||
Protocol openyes=can be implemented based on published detailed specification, no=no source published, partial=needs reverse engineering based on rough specs or source code | yes | BTP - a transport layer security protocol for delay-tolerant networks w | yes | yes | yes w w | yes w | yes | yes w | yes | yes w w | no | yes w | yes w | yes w | undocumented | yes w | yes | yes | yes w w | yes w | yes w | not documentedNeed to reverse engineer from source code | some yes | yes w | yes w | yes w | yes w | yes w w | yes w | yes w | yes w | yes w w w | no | no | yes w | yes w | ARP open w others in prose w | yes w w | no | open protocol, no way to verify because closed service platform | no | yes w | ||||||||||||
Server license | MIT w | various (any SMTP and IMAP server) | Proprietary | Nameservice GPL-3.0-only w OpenDHT GPL-3.0-or-later w | proprietary | proprietary | Apache-2.0 w | N/A | BSD-3-Clause w w | proprietary | proprietary | GPL-3.0-only w | AGPL-3.0-only w | proprietary | GPL-3.0-only w MIT w | AGPL-3.0-only w | proprietary | proprietary w | proprietary | proprietary | proprietary: Chat, Directory, Media | proprietary | proprietary | proprietary | various | proprietary | proprietary | |||||||||||||||||||||||||||
Client license | Apache-2.0 w | GPL-3.0-or-later w Desktop AGPL-3.0 w | GPL-3.0-only w | GPL-3.0-only w | MIT w | GPL-3.0-or-later w | GPL-3.0-or-later w w | AGPL-3.0-only w | GPL-3.0-only w | AGPL-3.0-only w | Proprietary | GPL-3.0-or-later | nosome libraries used by keet are published under Apache 2.0, but not enough to build a client from w | BSD-3-Clause w | Apache-2.0 w | GPL-3.0-only w | GPL-3.0-only w | 2BSD w | GPL-3.0-only w | BSD-3-Clause w w | GPL-3.0-only w | GPL-3.0-only w | AGPL-3.0 w w | GPL-3.0-only w | GPL-2.0-only w | MIT w | AGPL-3.0-only w | GPL-3.0-only w w | GPL-3.0-only w w | proprietary | Apache-2.0 w w | GPL-3.0-only w | CC-BY-NC-SA w | Android GPL-3.0-only w iOS GPL-3.0-only w Desktop AGPL-3.0-only w | GPL-3.0-only w | GPL-3.0-only w | AGPL-3.0-only w | proprietary | proprietary w | GPL-2.0-only w TelegramSwift GPL-2.0-only w Desktop GPL-3.0-only w | GPL-2.0-only w | AGPL-3.0-only but paid | GPL-3.0-only w | proprietary | proprietary | proprietary | various | BSD-2-Clause w w | proprietary | |||||
Register without app | yes | No registration necessary. | yes | yes | No registration necessary. | supports existing mailbox provider accounts w | yes | yes | yes | no | Attached to Apple IDIf you have an Apple ID you already have an iMessage and just have to enable iMessage with that account on whatever apple device you are on. You can also have a phone sim with a phone number, in which case iOS will automatically register you for iMessage with that number upon boot. | no | no w | Web | yes | no | no | yes | yes | no | yes | clients connect via Tor BrowserJavaScript required, accounts are per group, not per user, but the server does need an app to create each group account w | yes | no | yes | no | yes | no | noas a workaround, through the unofficial mautrix-signal matrix bridge with a custom HS | noas a workaround, through the unofficial mautrix-signal matrix bridge with a custom HS | noas a workaround, through the unofficial mautrix-signal matrix bridge with a custom HS | No registration necessary. | no | no | no | no | no w | no | no | no | ||||||||||||||
User features | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Spell checkGrammar correction, languages | noNo spell check | not yet w | no w w | Included in all the platforms that iMessage supports | no | yes | yes | yes | yes | |||||||||||||||||||||||||||||||||||||||||||||
Repliesno=cite-only, partial=jump to message by ID, yes=thread sidebar by conversation ID | nomissing XEP-0461 w | yes w | nomissing XEP-0461 w | nomissing XEP-0461 w | cite w | replies w w w | repliesXEP-0461 w | replies w | repliesXEP-0461 w | no | replies w w | cite w w w | no | no w w | yes w w | nomissing XEP-0461 w | yes w w | nomissing XEP-0461 w | nomissing IRCv3 +draft/reply w | yes w | replies w | yes w | ||||||||||||||||||||||||||||||||
Group chatWhether they are persistent between restarts, chat log, file transfer, inline images, offline messaging | yesw OMEMO encryption in group chat session enhancing privacy and security | yes w | yes | yes | experimental w group chats w | yesw membership change is unicast | yes w | yes | yes | yes w | yes | no w | yes w w | yes | no w | yes w | yes w | yes | ephemeral, no logs w small images w | yes | yes | yes w | yes | yes w w | yes w | yes | One community/team only w | yes | closed groups (private) e2ee, open groups (public) not e2ee w | yes w | yes w | yes w | yes w | yes | yes w | yes | yes | implemented with unicast w w | invite-only w | yes w | up to 256 members (higher with exploits)w | yes | ||||||||||||
Voice calls | yesw | no w | yes | yes w | not yet w w | via embedding jitsi, talky.io, appear.in w | WebRTC w | no w | Provided through facetime integrationencrypted w | partial wHave tested Jami for about a year, and calls are not working reliably, if at all. | yes w | WebRTC w | yes w | yes w | yes w w | yes | yes w | yes | no w | no w | no w | no | WebRTC w | beta test, p2p, ip exposed w | yes w | yes w | yes w | yes wterminal app via WebRTC in browser | yes | yes w | yes | yes | yes w | yes w | yes | yes | ||||||||||||||||||
Video calls | yesw | no w | yes | yes w | not yet w w | via embedding jitsi, talky.io, appear.in w | yes w | WebRTC w | no w | Provided through facetime integrationencrypted w | partial wJust like with calls, Jami isn't intercepting video-calls reliably | yes w | WebRTC w | yes w | yes w | no w | yes | no w | yes | no w | no w | no w | no | WebRTC w | beta test, p2p, ip exposed w | yes w | yes w | yes w | yes wterminal app via WebRTC in browser | yes | yes w | yes | yes | yes w | yes w | yes | yes | |||||||||||||||||
Group callsAudio, video | no | no w | no | no | not yet w w | via embedding jitsi, talky.io, appear.in w | yes w | via Jitsi w | no | yes | by forwarding by the initiator w w | up to 10-12 people w | Jitsi Bot w Zoom Bot w Google Meet Bot | via Jitsi w | no | yes w w | yes w | yes | no w | no w | no | via Jitsi w | no | yes w w | yes w | yes w | no | yes | yes w | yes | yes | on Android w and iOS w | yes | yes | ||||||||||||||||||||
Voice messagesIdeally push to talk, may be useful where voice call is not supported. Also voice notes | no | no w | yes | yes w | yes | yes w | yes | no | only in mobile clientOr even only Android? seems like no? w | yes w | no | yes | yes w | yes | yes w | yes | yes | yes | voice notes, limited to certain length | yesw | yesw | yes | yes | |||||||||||||||||||||||||||||||
Screen sharing | no | no w | requires iOS or iPados 15.1 or laterw | no | yes w | no | yes w | yesw there is also a way to do it using obs, but citation needed. | yes w | no | yesw there is also a way to do it using obs, but citation needed. | yesw there is also a way to do it using obs, but citation needed. | ||||||||||||||||||||||||||||||||||||||||||
Audio filteringNoise cancellation, gain control, voice activity detection | no w | no controlsAppears to filter audio by default, no apparent controls over this | no | no | aggressively detect and cancel the background noise | |||||||||||||||||||||||||||||||||||||||||||||||||
File transferRetry, pause, resume | no w | yes | yesXEP-0363 w | experimental w | small files w | yes w | yesXEP-0234 XEP-0261 XEP-0363 w | yes w | yes w w w | yesadditionally E2EE storage and shares w | yes | no | yes | only inline images w w w | yesnote it does compress images and video by default w | up to 220kB w | partial wRight now basic attachement | yes w | no | yesnote it does compress images and video by default w | yesnote it does compress images and video by default w | yes w | yes | yes | ||||||||||||||||||||||||||||||
Message formattingFont size, bold, italic, underline, strike-through, list, blockquote, code, pre, colors, clickable link, table, subscript, superscript, line break, horizontal rule | no | yes | sends text w renders HTML w w w w | yes | XEP-0393 w | no | partialbold, italic, strike-through preformatted, ordered list, unordered list w | CommonMark-flavored markdown w w | no | basic w w | yes | yes w w | no w | no w | markdown w | no | ||||||||||||||||||||||||||||||||||||||
Unicode supportyes=can both send & receive text containing any valid Unicode code point, usually via utf8mb4, partial=does not support 4-byte+ UTF-8, certain characters or combiners | yes | partial | yes | no | yes | |||||||||||||||||||||||||||||||||||||||||||||||||
Emoji composeryes=rich dialog with search, partial=replaces a few emotes or aliases with Unicode before sending | no | partial w | yes | Built into keyboardAll platforms that iMessage support after around iOS 6 support some way to open an emote keyboard from a keyboard button/shortcut. After iOS 14 you can search through the emote keyboard. Somewhere around this same time Apple implemented emote suggestions in the keyboard suggested text buttons. | yes | yes | yes | no | no | yesemote button and use : and start typing to put emotes quickly | yes | yes | yesemote button and use : and start typing to put emotes quickly | yesemote button and use : and start typing to put emotes quickly | yes w | yes | ||||||||||||||||||||||||||||||||||||||
Emoji receptionyes=color Unicode display of all, mention in details if animated, partial=monochromatic, only a subset or replaces received emoticons with pictures | FIXME | FIXME | yes | FIXME | bundled or platform w | FIXME | yes | FIXME | yesYes, assuming device is up to date as emotes are rendered through the operating system | yes | yes | yes | no | FIXME | FIXME | FIXME | FIXME | FIXME | yes | FIXME | FIXME | FIXME | FIXME | FIXME | FIXME | FIXME | FIXME | FIXME | FIXME | FIXME | ||||||||||||||||||||||||
Sticker packsWhether they are animated | no | with EweStickers from F-Droidw | yes | Built inIncludes some by default, install more and iMessage extensions through the app store | no | mostly through vendor w w w | no | yes w | yes w | yes | yes w | yes w | yes w | via 3rd party keyboards | animated sticker packs available | yesw | yesw | yes | yes w | |||||||||||||||||||||||||||||||||||
Link previewUnfurling: who downloads the page, the sender, recipient or the server of one or the other | yesw Share of social media links are tagged with thumbnail and title | no | no | nocan be simulated by a bot in group chat w | no | Downloads sender side before message is sent to Apple | no | yes | no | yesclient side by sender, can be disabled in settings w | recipient client w | yes w | yes w | no | no | no | yesclient side by sender, can be disabled in settings w | yesclient side by sender, can be disabled in settings w | yesclient side by sender, can be disabled in settings w | yesUser setting to generate link preview upon sending. | small embed for link, tapping opens in app browser previewprimarily used for ads | yes w | yes w | yes | ||||||||||||||||||||||||||||||
Inline imagesSupported image formats: png, jpeg, gif, webp, avif | yes w w | yes | attachments separatelycould be implemented within HTML messages w | yes | yes | FIXME | yes | yes | no | yes w | small ones w | yes | yes | yes | yes | yes wmobile | yes | yes | yes | yes w | yes | |||||||||||||||||||||||||||||||||
Inline videosSupported video formats: mp4, webm, av1 | yes w | attachments separatelycould be implemented within HTML messages w | yes | FIXME | yes | yes | no | yes | yes | no w | yes w | yes | yes | yes w | yes | |||||||||||||||||||||||||||||||||||||||
PollsMultiple choice voting | no | no | no | no | Potentially available through iMessage extension | no | no | yes | no | no | yes w | no | no | yes | yesw | yesw | yes w | |||||||||||||||||||||||||||||||||||||
Reactionsyes=Various emoji, partial=only upvoting | nomissing XEP-0444 w | no | nomissing XEP-0444 w | no w | no | yes w | yes w | yes | Few reaction options | FIXME | yes | all common Unicode emojino custom images, custom text in certain clients | no | yes w | no w | nomissing XEP-0444 w | yes w | yes | nomissing XEP-0444 w | no w | no w | yescustom text natively supported | yes w | yes w | yes w | yes w | yesw | yes w | yes w | yes | ||||||||||||||||||||||||
Read public content without registeringProvides free tasting to look around before committing to install anything or having to remember another pair of credentials | partialonline public mailing list archives | guest participant, room peek preview, static HTML view w w | no | Must have an apple device to use | no | no w | no | guest participant, room peek preview, static HTML view w w | no | no | no w | guest participant, room peek preview, static HTML view w w | 5 official rooms are bridged w | Install required to accept an open inviteEven if a room has an persistent and public group link (the closest thing to being public), a user needs to install a client and join the room before being able to read messages. | no | no | no | no | no w | |||||||||||||||||||||||||||||||||||
Multiple devicesIf the same account can be used at the same time from multiple devices, syncing contacts, messages and notifications. | yes | no w | yes | yes | yes w | yes | yes | yes | "It is still difficult to get reliable chats between different devices." w | Sync through icloudYou can sync messages through iCloud e2ee, however contacts etc. are not e2ee when synced, and the encryption key is included in iCloud backups (not e2ee) of the device if enabled w | yes w | nothey recommend joining in multiple devices via separate accounts, not sure whether reusing the key would work at all w | yes | yes | no | Any Android device as linked device w | yes | yes | yes | just paste the private key on each w | yes | no | yes | no w | yes | still not functioning properly | Only Desktop as secondary device | no | no | Using mobile profiles from desktop | yes | requires log out and log in, but chat stays in cloud accessable on both devicesw | yes | yes | as group chat w | |||||||||||||||||||
Online account replicayes=everything available in the cloud from any device, partial=not all of credentials, profile, settings, contacts or conversations | no w | partial | IMAP + manual backupthe account needs to be exported/imported periodically w set up and keep online a secondary device as an alternative | yes | iCloud backup requiredRequires iCloud backup of device which is not e2ee w | no w | yes | yes | local backup w | yes | contacts w no messages w | is web based | ||||||||||||||||||||||||||||||||||||||||||
Multiple accountsIf you can stay logged in with multiple accounts on the same device and application without external isolation techniques | yesw | no w | yes | yes | yes | yes w w | yes w | only the first logged in account will receive push notifications | yes | yes w | no | no | yes | Web tabs, Desktop profiles | noIP/MAC is your identifier | no | yes | Unlimited | yes wcommand line flag --profile | partialcould connect via multiple Tor browser instances | yes | no | yes | no | no | no | no | no | yes w | no | no | 3 | 3 | no | ||||||||||||||||||||
Application lockingUnlock the account or certain chats with a PIN code, passphrase, fingerprints or facial likeness | no | Android's screen lock w | no | passphrase on app startno other type of locking at the moment | Android - custom 4 digit PIN | no | no | no | Android w iOS w | password on start-up w | Passphrase & Biometric w | no | Android - custom 4 digit PIN + system fingerprint w | Android w | Android's screen lock w | Android's screen lock w | Android's screen lock or passphare w | Android - custom 4 digit PIN + system fingerprint w | Android - custom 4 digit PIN + system fingerprint w | Android's System Screen Lock, PIN or Biometric w | also on desktop, individual chats too w | |||||||||||||||||||||||||||||||||
Remote message removalAlso called redaction, retraction or deletion | last messageby editing last message XEP-0308 w as XEP-424 and XEP-425 missing | no | no | no w | last messageonly by editing last message, XEP-0424 and XEP-0425 missing w | no | no w w | yes | by redaction events w | no | within 3 hours w | last messageonly by editing last message via XEP-0308 as XEP-0424 and XEP-0425 missing w | partial w | nomissing XEP-0308, XEP-0424, XEP-0425 w | no | no w | no | within 3 hours w | within 3 hours w | can be disabled w | yesmobile, in console there's whole history visible e.g. 21:37 a11> ff 21:37 a11> [deleted] ff | no | partial w | partial w | no w | yes | ||||||||||||||||||||||||||||
Remote message correctionAlso called editing | last messageXEP-0308 w | no | no | no w w | last messageXEP-0308 w | last messageXEP-0308 w | no | no w w | yes | yes | no | within 24 hours w w w | last messageXEP-0308 w | nomissing XEP-0308, XEP-0424, XEP-0425 w | no | no | within 24 hours w w w | within 24 hours w w w | within 24 hours w w w | yes w | no | only with secret chats (e2ee) disabled | no w | no | ||||||||||||||||||||||||||||||
Message expirationAlso called retention time, disappearing/ephemeral/self-destructing messages | XEP-0466 missing w | Only setting of 7 days possible in private messages w | no | XEP-0466 missing w | yes w | XEP-0466 missing w | no | XEP-0466 missing w | Only on voice messages*Message expiration only occurs on voice messages and it is set to either 2 minutes or never by the receiving party, and there is a keep message button (that notifies the sending party "_ kept a voice message") | no | no | yes w | per room, no GUI, not defaultonly through slash-commands in Element, need to enable on each Synapse home server and depending on configuration in each room as well w | no | yes w | no | 1:1 secret chats and some media, only on mobileOnly for 1:1 secret chats (not default) on mobile and media in private cloud chats w | no | no | no | no | up to 7 days client side, server mirrors for 14 daysdisappearing messages (local) 5 sec - 1 week options, server keeps all messages for 14 days w | yes w | yes w | yes w | yes w w | no | retained indefinitely on their servers | 1:1 secret chats and some media, only on mobileOnly for 1:1 secret chats (not default) on mobile and media in private cloud chats w | 1:1 secret chats and some media, only on mobileOnly for 1:1 secret chats (not default) on mobile and media in private cloud chats w | no w | yes w | yes | |||||||||||||||||||||
Presence statusWhether it is supported. This can actually be a privacy breach for tinfoil | yesXEP-0319 w | for groups only contacts w | yes | yes | 1/1 chats show when contact offlineFor 1/1 chats it's not possible to send message when contact offline, when online text input is available. No indication in group chat about members status. w | XEP-0319 w | no | no | no | with performance issues w | yes w | no w | yesXEP-0319 w | yes | yes w- Shows online status of the people you are talking to. - You can define a custom status message to tell others what you are currently up to. - The status message appears next to the usernames in the timeline. - Your server needs to have presence enabled for this to work. | yesStandard IRC protocol status | HS capability | no w | no w | no w | yes | yes | yes | yes | ||||||||||||||||||||||||||||||
Presence not mandatoryIf has presence broadcasting, can it be hidden when online | no | receipt part optional w | yes | no | no w | yes | yes w | yes | yesStandard IRC protocol status | partialAndroid can disable it - w | yes w | yes w | yes w | |||||||||||||||||||||||||||||||||||||||||
Typing indicationWhether sending and showing is supported. Mention in the explanation whether it can be disabled and its default state | no | can be disabled w | no | no | yes wtoggle on/off both globally and per conversation | cannot be disabled w | Can't be disabled | no | can be disabled | yes | no | yesshowing and sending can be switched off together w | can be disabled w | cannot be disabled w | can be disabled | no | can be disabled | does not work on desktopshown and sent by default but can be switched off w | yesshowing and sending can be switched off together w | yesshowing and sending can be switched off together w | yesshowing and sending can be switched off together w | "live" messages w | yes | cannot be disabled w | cannot be disabled w | yes | ||||||||||||||||||||||||||||
Read receiptsWhether sending and showing is supported | yes | only delivery receipt w | yes w | yesXEP-0333 w | only delivery receipt | yes w w | yes w | yes | yesXEP-0184 XEP-0333 w | yes | no | no | yes | no | yes w | yes w w | yes w | yes | yes w | no | yes | yes w | yes w | yes w | delivery receipts only w w | yes w | yes | yes w | yes w | yes | ||||||||||||||||||||||||
Receipts not mandatoryyes=they can be disabled, note default value | yesNot mandatory | yes w | yes w | yes wtoggle on/off both globally and per conversation | no | yes | no | no w | yes | yes w | yes w | no | can be hidden on client only | can be hidden on client only | yes w | yes w | yes w | yes w w | yes w | no w | no | no | all or nothingYou have to disable read receipts completely and then you wont be able to see other's receipts. Also they are always sent in group chats. w | |||||||||||||||||||||||||||||||
Themesno=1, partial=2, yes=more - Appearance, dark scheme, night mode, OLED, prefers contrast, reduced motion, color blind, custom base color, large fonts, visual style presets, automatic switching | partial wlight/dark | partial w | partialdark/light with accent color | Light and dark mode with system | no | yesseveral themes, message bubbles, irc style etc | partiallight/dark | yes wlight/dark theme with customizable bubble colors | partial wlight/dark | yes wlight/dark theme with customizable bubble colors | yes wlight/dark theme with customizable bubble colors | yes wlight/dark theme with customizable bubble colors | yes w | partial wlight/dark | yes wfull customization | yes wfull customization | ||||||||||||||||||||||||||||||||||||||
Qualities | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Landing pageIntroductory website maintained by vendor, may use SaaS subdomain | dynamic DNS w SaaS w | yes w | yes w | yes w | clearnet w Tor w | yes w | yes w | yes w | yes w | yes w | yes w | yes w | yes w | yes w w | yes w | yes w | partial w | yes w | yes w | yes w | yes w | partial w | yes w | yes w | ||||||||||||||||||||||||||||||
ManualKnowledge base maintained by the vendor, user manual, tutorial, extensive FAQ, URL | yes w | yes w w | no | partial w | yes w w | yes w | partial w | partial w | yes w | yes w w | yes w | yes w | no | yes w | yes w | yes w w w w | partial w w | no | yes w | yes w w w | yes w | no | no | yes w w | ||||||||||||||||||||||||||||||
Vendor can't curate contentno=vendor can influence who can access which content, remove spam and vandalism | yes | yes | only mailbox provider w w | Vendor doesn't provide a homeserver | in any room the vendor doesn't admin | yes | self-hosting | yes | fully self-hosted | yes | ||||||||||||||||||||||||||||||||||||||||||||
Spam protectionIf it gained worldwide adoption | noXEP-425 missing w | partialXEP-0425 w | partial wCould result in an increase in network bandwidth which may be intolerable or undesired for many people - especially those on metered connections | standard email filters, hides non-contact w w | no | no | collapse voting w w | blocking and reporting w | partialprovided through third-party tools, such as Mjolnir: w | ignore unsaved w w | partialXEP-0425 w | partialXEP-0377 w | Groups are invite-onlyThe server could implement filtering in the future | no | proof of work w | proof of work,unlimited account ids can be generated almost instantly | limiting messaging non-contactsw | invite code w | spam checker, limit invitesselect who can add you to group chats w | |||||||||||||||||||||||||||||||||||
Account deactivation after device compromiseSolvable with centralized or federated servers or with revocation certificates in P2P. | no | yes | yes | no | partialprobably manually by a revocation certificate and with the help of the mailbox provider | yes | yes | yes | yes w | no w | device revocation w | with second device or Web or Desktop | no | Only for secondary devices | yes | Only for secondary devices | yes | Private key distributed | yes | yes | no | yes | account ids are random generated 2^128 keys | Only for secondary devices | Only for secondary devices | Only for secondary devices | No user accounts | Only for secondary devices | Only for secondary devices | yes w | ||||||||||||||||||||||||
Account recovery after device compromiseSolvable with centralized or federated servers or with subkeys, revocation and secret sharing in P2P. | no w | yes | no | partialprobably manually by revocation, mailbox provider help, generating new keys and verifying all contacts again | yes | no w | no w | second device or paper key w | with second device or Web or Desktop | no | yes | Private key distributed | partial w | yes | accound ids can be recovered with seed phrase, 12 words + 1 check word | only after phone number is reclaimed w | no | |||||||||||||||||||||||||||||||||||||
CPU idleno=Proof of work, partial=sluggish due to idling too little in foreground or measurable amount of processing in background, yes=otherwise | yes | uses more due to P2P w | uses Tor browser | proof of work w | Uses proof of work to combat spam | yes | ||||||||||||||||||||||||||||||||||||||||||||||||
Power savingEnsure that device wakes up as few times as possible, filters and batches events on remote side, no open sockets, delegated peer tracking | IMAP IDLE keeps a socket open | partial offload by OpenDHT proxy wbackground transfers deplete the battery faster noticeably | uses more due to P2P | yes w | uses Tor browser | Constantly transfers in the backgroundopen groups use polling w | ||||||||||||||||||||||||||||||||||||||||||||||||
Bandwidth frugalConservation by lazy loading, previews, adaptive detail, incremental sync, fewer round trips, tokenization, batching transfers to improve compression, tweaked key schedule, multicasting hubs | no | group messages are unicastshould use selective IMAP fetches and compression | transfers constantly in the backgroundaccording to testing by editors | uses more due to P2P | partial w | uses Tor browser | nomulticast as unicast w constant peer exchange and buffering for everyone | Constantly transfers a lot in the background36MB/hour in our Desktop test in 2022, open groups use polling w | Very aggressive message padding, group chats are unicastSee w | Push relay & native push, group chat via unicastFetches encrypted content from its own server in response to a push, optimized binary chat protocol w | ||||||||||||||||||||||||||||||||||||||||||||
Disallow screenshotspartial=Only for yourself, yes=Ask peers to not take screenshots of message or conversation. Also called screen security | Android wThis does not provide any real world usage, especially for the tinfoil persona. Any conversation partner can use screen-share capabilities to capture and record messages without alerting their chat partner. | no | only for yourself w w | no | no | no | only for yourself on Android w w | no | no | no | only for yourself on Android w w | only for yourself w | only for yourself w | only for yourself w | only for yourself, Android w | |||||||||||||||||||||||||||||||||||||||
LogoAvatar, prefer FOSS, externally hosted, Wikimedia URL | yes w | yes w w | yes w | yes w w | yes w | yes w w | yes w w | yes w | yes w w | yes w w | yes w | yes w w w | yes w | yes w w w | yes w | yes w w w | yes w | yes w | yes w w | yes w w | yes w w w | partial w | yes w | yes w w | ||||||||||||||||||||||||||||||
Security | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Threat modelyes=maintainers have made the #threat_model accessible and/or obvious | no | yes w | yes w w | yes w | yes w | yes w w | no | yes w | no | yes w | yes w | |||||||||||||||||||||||||||||||||||||||||||
End-to-end encryptionThis is more important for closed or non-self hosted servers | yes wEnd-to-End encryption with OMEMO or OTR | yes w | XEP-0384 OMEMO walso OpenPGP | XEP-0384 OMEMO walso OpenPGP | Profiles are stored locally on disk and encrypted w | yes w | XEP-0384 OMEMO walso OpenPGP | yes w | yes w w | FIXME w w w w | yes w | yes w | yes w | yes w | no w | Only for 1:1 secret chats (not default) w | yes w | Tor hidden service hubMITM possible, separate encrypted Tor channels between the server and clients w | yes w | no | yes w | yes w | yes in private conversations and closed groups, no in open groups w | yes w | yes w | yes w | 2 layers w w w | Only for "Private converstations" (not default) w w | no, but delivery is encryptedSnaps are encrypted in transit and until viewed by recipient, not E2EE | Only for 1:1 secret chats (not default) on mobile w | Only for 1:1 secret chats (not default) w | yes w | yes w | default w | yesw | |||||||||||||||||||
E2EE keys shielded from operatorRegardless of this, certain OS vendors might also have access to your keys | yes w | Key included in iCloud backup of deviceThe backups are not client-side encrypted. When you disable backup a new key is generated so Apple doesn't have access to your past messages any more w | yes w w | FIXME | yes w | yes | 2^128 generated locally w | yes w w | yes w | yes w | ||||||||||||||||||||||||||||||||||||||||||||
DeniabilityDeny sending a message, repudiability | now DKIM and received mail headers reduce feasibility | no | partialTODO: couldn't the server correlate messages of a client? | no | yes w | no | public-key authenticators w | |||||||||||||||||||||||||||||||||||||||||||||||
Replay preventionOf third party buffering nodes | yesBTP achieves forward secrecy by periodically rotating and deleting the temporary keys. This prevents replay attacks, in theory, but only in rotation mode, which provides Forward Secrecy. w | noDKIM could already provide all needed information | no | noTrivial to repeat a message as it's anonymous with chosen display name | yes w | nonce accumulation w | ||||||||||||||||||||||||||||||||||||||||||||||||
Downgrade resistanceMitigation against downgrade attacks | no | yes | yes w | |||||||||||||||||||||||||||||||||||||||||||||||||||
Contact list confidentialIf the client never sends over its contact list to the server | yes w | Contacts are stored on the server.Self hosting of ones own server is easy and recommended. | not published, but leaks through mail headers w | Decentralized, no server. | no | no | yes w | yesTODO: Are we sure a server running multiple rooms or clients connecting to multiple rooms aren't able to correlate their peers? | yes w | partial | yes w | noserver likely has a copy at all times and keeps older versions | stored on device, optional address book import w | yes w | ||||||||||||||||||||||||||||||||||||||||
Metadata protection | yesvia onion routing | yes w | encrypts certain email headersrecipients and time in the clear w | no | username across rooms, LAN leaksw user handles shared across rooms, connections can relay via other peers and each room uses a unique id key | no | no | sealed sender traffic analysis w w groups v2 downgrade w w | no | partial w | partial | sealed sender traffic analysis w w groups v2 downgrade w w | yes w | no | yes w | no | ||||||||||||||||||||||||||||||||||||||
Perfect forward secrecy | no | 1-1 yes w groups no w | no w | yes w | no | 1-on-1 yes, groups partialyes for 1-on-1 conversations. partial for group conversations w | yes w | manually w | yes w | was explicitly removed from Session protocol w | yes w | yes w | yes w | yes w | for single chats on Android w and calls w | yes w | yes | |||||||||||||||||||||||||||||||||||||
Security teamyes=regularly scanning for vulnerabilities proactively, found bugs inspected for security implications, partial=reported vulnerabilities promptly fixed and released | no | partialWhile there is no dedicated security team, code reviews are in place as well as any reported vulnarabilities will be fixed ASAP. | yes w | yes | included as part of the system | bugs not categorized based on security impact w | no | partial | partialno security response strategy, no fixes tagged with security w | partial w | ||||||||||||||||||||||||||||||||||||||||||||
Large bug bounty | no | yesw | no | third-party w | no | yes w | no w | |||||||||||||||||||||||||||||||||||||||||||||||
Reproducible builds | yes w | partial w w w | Not FOSS | no w | proprietary | no w w | no w | yes w | no w | Android w | yes wFOSS does not merge into master, linking latest build as of entry added to the chart | yes w | yes w | iOS, Android w | Android w | bootstrap daemon w | ||||||||||||||||||||||||||||||||||||||
Audits | 2017 w | 2019 w 2020 w 2023 w 2023 w | no | no | 2018 w | crypto library in 2016 w | no | no | 2020 w | no w | no w | one completed, covered only session protocolnetwork and servers have not been audited w | multiple w | 2022-11-03 by Trail of Bits w w | 2023, 2020, 2019 w | no | ||||||||||||||||||||||||||||||||||||||
Usage without phone number | yes | yes | yes | yes | yes | depending on mailbox provider | yes | yes | yes | yes | Requires email attached to Apple ID to be public instead | yes | yes w | yes | yes | yes | no | yes | yes | no | yes | yes w | yes | yes | yes | yes | yes | Random 2^128 key generated as account id w | no | no | no | yes | no | no | yes | yes w | Phone number based | yes | ||||||||||||||||
Sustainability | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Transparent financingyes=it is clear how the project can operate indefinitely, no=we know nothing, partial=public statements were made but not convincing | no | yesw | Funded by MBOA and JMP.chatw MBOA is the development team behind JMP and Sopranica. | yes w w w | grants, funds, Liberapay, PayPal, bitcoin w | no w | no | 2018 GSoC w w | Donations w | noCouldn't find any donation links, previous sponsorship or how supportive their community is w | complex financial structure with no clear answersnetwork is financed by oxen crypto, financial disclosures haven't been published since 2019 w | yes w | out of pocketnot currently accepting donations w | cryptocoin backed by VC w w | ||||||||||||||||||||||||||||||||||||||||
No-cost tier | yes | yes | yes | Only paid content would be third party extensions | yes | yes w | yes | yes w | yes | yes w | yes w | yes | yes | yes | yes | yes w | yes | entirely free platform | yes | yes | no | yes w | yes | yes | no w | |||||||||||||||||||||||||||||
Payment choicesyes=cryptocurrency or some other anonymous, partial=lots of inexpensive choices | N/A | N/A | Apple Pay or any payment app with an iMessage extension | N/A | GitHub sponsorship w | Open Collective w Monero w | N/A | N/A | none | Google Pay, Apple Pay, cryptocurrency w | Wire transfer, MasterCard, Visa, PayPal, Bitcoin, Cash w w | N/A | ||||||||||||||||||||||||||||||||||||||||||
Active developmentyes=developer availability is not a bottleneck for progress, partial=occasional hobby development or basic maintenance work, no=no development or only ensuring it builds | yes | yes | yes | yes w | yes | yes w | yes w | yes w | yes w | yes | FIXMEMany basic features went missing for years and there seems to be little progress | maintenance mode w | no w w | yes w | yes w | yes w w | yes w | yes | yes | yes w | yes | yes | yes w | yes | yes | yes | yes | yes | yes | yes | yes w | yes | yes | |||||||||||||||||||||
Multi-party developmentno=one-man show, yes=highest level contributors are exchangeable, equal drivers, partial=regular contributions from multiple people | no | partialOne main developer, but contributions from others are readily accepted. | no | partial w | 10 git members w 31 authors w | partial w | partial | partial | FIXME | partial w | no w | yes w w w | Hacktoberfest w GSoC-22 w | nosingle, anonymous person behind it w | partial w | yes w | yes w | |||||||||||||||||||||||||||||||||||||
Isolated self-hostingIt can be deployed on-premise in a LAN without internet | SMTP and IMAP w | yes | no | complicated w | no w | no | yes | no | Requires Tor | no | no | no | no | yes | no | no | ||||||||||||||||||||||||||||||||||||||
User can extend network with nodeImproving the scaling of the system and communicate with anyone (i.e., if P2P or federated) | Applicable to group chats only w | SMTP and IMAP w w | yes | Proprietary system | many parts self-hostableOpenDHT proxy, bootstrap, TURN, Jami blockchain, Jami name server w | yes w w | no | yes | no | no | All networks isolatedA user can either start a separate one or join an existing one | yes w | no | no | no | no | yes w | no | no | no | no | each client is full node w | ||||||||||||||||||||||||||||||||
Identity not controlled by vendorWill the system still work if the developer goes bankrupt | yes | yes | yes | yes | SMTP and IMAP w | yes | yes | yes | no | names are optional and stored on a blockchain w w | no code or documentation | no | Unless using matrix.org accountvendor also offers various self-hostable or optional services like stickers, bots and bridges | yes | no | yes | yes | no | yes | Generated when starting server | yes | yes | partial | no | no | no | yes wself-hosted servers defined in the apps | no | no | no | no | no | locally generated w | no | no | |||||||||||||||||||
Open documentationCopyleft, editable by users through a wiki or source code repository, URL | yes w | yes w | no | partial w | yes w | yes w | yes w | yes w | yes w | yes w | no | yes w w | no | yes w | yes w w | yes w w | partial w | partial w w | yes w w | yes w w w | yes w w | no | no | yes w w w | ||||||||||||||||||||||||||||||
Web forumPublicly readable, URL | no | yes w | no | no | no | yes w | no | no | no | yes w w w w | yes w | yes w w | no | yes w | yes w w | yes w w | no | no | no | no | yes w w | no | no | yes w w | ||||||||||||||||||||||||||||||
ContactURI including the scheme prefix, preferably of group chat, such as matrix: acct: xmpp: msrp: news: mailto: irc: sip: mumble: ssh: | no | yes w w | yes w w | yes w w | yes w | yes w w | yes w w w | yes w w | yes w w w w w w | no | yes w w w w | no | yes w w | yes w w w w w w | no | yes w w w | yes w w w | yes w w w w | yes w w w w | partial w | no | |||||||||||||||||||||||||||||||||
SyndicationURL of RSS, Atom, twtxt or gemini text feed | no | yes w | no | no | yes w | yes w | yes w | no | yes w | yes w | no | yes w | yes w w | no | no | yes w w | no | no | yes w | no | yes w w | no | yes w | yes w | ||||||||||||||||||||||||||||||
Topology | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Offlineno=Not useful if disconnected. partial=Only read a few buffered messages or compose new ones. yes=Reboot, add new contacts, past logs, search, cache list of groups or users, settings. | noCan't be used without internet | no | yes w | compose or read recent messages on Mobile/Desktop, no Web startupBuffered messages on Mobile/Desktop, Fluffychat Web lacks offline startup via Web Workers | yes | yes w | no w w | no | compose or read recent Desktop messages, no Web startupBuffered messages on Element Desktop, Element Web lacks offline startup via Web Workers | list&add contacts w | no | Compose or read stored messages | compose or read stored messages | up to 28 days w | compose or read recent messages on Android/Desktop, no Web startupBuffered messages on SchildiChat Android/Desktop, SchildiChat Web lacks offline startup via Web Workers | yes w | Compose or read stored messages | Compose or read stored messages | Compose or read stored messages | not possible to add contact | Compose or read stored messages | Compose or read stored messages | Compose or read stored messages | yesTODO: verify and add reference, because it requires many servers to run | buffering, personal proxy w w w | Compose or read stored messages | yes | |||||||||||||||||||||||||||
Servers requiredList all server software or instance by name that are mandatory to keep this network running or to host it in isolation | XMPP server | Tor w | Tor, Cwtch | DNS, SMTP, IMAP | Matrix homeserver e.g. Synapse, Dendride, Conduit, notifications push via FCM or Unified push | DNS, OpenDHT proxy, GCN/Apple push, bootstrap, TURN w | Holepunch, bootstrap (existing peers may be substituted), software updates, Google and Apple for notifications on mobile | Synapse homeserver, notifications push | Ejabberd or Prosody w | Matrix homeserver | Tor, OnionShare | live nodes on the preloaded list w w | IRC server | Matrix homeserver e.g. Synapse, Dendride, Conduit, notifications push, Unified push, backround synchronization service | session/lokinet onion routing network required w | SMP w | FCM | FCMWon't work on LineageOS | ||||||||||||||||||||||||||||||||||||
Servers optionalList all server software or instance by name that can provide extra features when using this network | jitsi, talky.io, appear.in w | Jami name server w | DNS, Element Web app, identity, integrations, ICE, Jitsi w | ICE (disabled) w w | w | FCM w or Threema Push w w , Threema Safe w | DNS | |||||||||||||||||||||||||||||||||||||||||||||||
Serverless WAN modeIf communicating over the internet might scale without (a vast amount of) dedicated servers, i.e. by supernode promotion and DHT | no | no | no | Requires Tor | SMTP is usually blocked | no | only data traffic is P2P(TODO: with IP and SIP?) w | no | no | nocan't cross NAT w | no | no | Requires Tor | can preload a node list wthere is no automated mechanism for updating or spreading this preload list with the client | no | no w | no | no | no | no | no | no | ||||||||||||||||||||||||||||||||
Serverless LAN modeIf you can communicate without an internet connection and a server | no | yes w | noXEP-0174 unimplemented in Conversations w | noXEP-0174 unimplemented w | Requires Tor | nomight be feasible in the future | noXEP-0174 unimplemented w | no | no w | no w | no | no | yes w | no | no w | Requires Tor | yes | no | no w | no | no | no | no | no | maybe w DHT generally needs WAN IP w | no | yes w w | |||||||||||||||||||||||||||
Network store and forwardYou can compose messages to your peer even if the two of you aren't online at the same time | if server and contact client support XEP-0313 MAM | if server and contact client support XEP-0313 MAM | yes w | yes | no w w | no w w w | no | yes | no w | yes | yes w | if server and contact client support XEP-0313 MAM | No chat log w | up to 2 days w | yes | messages are stored on session servers for 14 days w | yes | yes | yes | yes | yes | no w | ||||||||||||||||||||||||||||||||
Wireless modeBuilt-in support for peering with nearby nodes over ISM wireless either to sync or as part of a mesh | Bluetooth w | no | no | no | no w | no | no | no w w | no | no | no | no w | no w | no | no | no | no | no | no w | |||||||||||||||||||||||||||||||||||
IP shielded from peers | not for STUN calls | not for STUN calls | via Tor | depends on providermost servers add SMTP client IP to Received header w | Not during calls if you enable WebRTC | FIXMEmessages can relay via other peers, blind forward is also implemented | not when using Jitsi, Zoom, Google meetings | Not during calls if you enable WebRTC | noMAC is also disclosed w | not for STUN calls | via Tor | Not during calls if you enable WebRTC | onion requests in private, group server operators, voice calls and video calls are p2pprivate conversations and closed groups are sent using onion requests, open groups are possibly visible by open group server operators, voice calls and video calls are p2p and ips are visible by all users, attachments, pictures, videos, files, etc. are not onion routed and are sent directly to and stored on session owned servers, avatars and user display names are possibly still uploaded directly to and stored on session owned servers, github contacted directly during account setup and when app checks for updates w | Requires using proxy w w | not if STUN calls are enabled w | p2p, not by defaultTox ID resolved through onion routing, Tor optional w | Not during STUN calls | |||||||||||||||||||||||||||||||||||||
Proxy supportHTTP, Tor, SOCKS5 | yes | only on desktop w | no | HTTP, SOCKS5command line client supports Tor w | no w | SOCKS5 w | SOCKS w w | |||||||||||||||||||||||||||||||||||||||||||||||
Vendor | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Third party clientsyes=Multiple full featured clients available, no=Terms of service prohibits access to vendor operated network | no alternative client | SMTP and IMAPinteroperates with any email client, E2EE uses AutoCrypt w | no | no alternative client | no | proof of concept TUI client based on Keybase CLI exists w Open API available w | yes w | no | yes | no alternative client | no alternative client | no w w w | yes | yes | openMittsu wIt is "tolerated" as of now | yes w | banned w | yes w | no alternative client | |||||||||||||||||||||||||||||||||||
Bots availableno=banned, yes=several available possibly from a built-in gallery | yes w | yes w | yes w | yes w | yes w w w w | yes w | yes w | yes w | no | yes w | yes w | no | yes w | yes w | yes w w | yes w | yesand many more for other protocols w | yes w | yesw | yes w w | yes w w | auto-inviter w | yes w | |||||||||||||||||||||||||||||||
User addonsApps, widgets, integrations by third party developers or users themselves | yes w w | Install through app storew | no | as bots w | yes w | no | yesw | |||||||||||||||||||||||||||||||||||||||||||||||
Hosted bots and addonsOptionally provided so that a user need not maintain a separate server | yes w | no | no | no | ||||||||||||||||||||||||||||||||||||||||||||||||||
Tor access of vendor operated networkyes=Without involving Tor exit nodes, no=Tor exit nodes blocked, partial=otherwise | N/Auses Tor connection to peers | routing and connections | N/Adepends on provider | no | CLI wthe website also has an onion address | no | via Orbot w | fully self-hosted | N/Auses Tor connection to peers | yes w | session/lokinet were designed to be non-compatible with tor | yes w w | yes w | |||||||||||||||||||||||||||||||||||||||||
IPv6 access of vendor operated networkStill green if only registration is limited to IPv4 | yes | N/Adepends on provider | no w | yes | yes w | fully self-hosted | yes | session is not currently compatible with ipv6, may be in future | yes w | |||||||||||||||||||||||||||||||||||||||||||||
Vendor operated network inaccessible from countriesIf it is illegal or blocked here or if the vendor prohibits usage or its infrastructure blocks users from here. Encryption itself is outlawed in many countries, do not list these. | N/Adepends on provider | China w | some countries attempt to censor Torbridges are available | possibly China is blocking access to Session and Lokinet | China, Iran, Uzbekistan, Cuba w | many and changing w | ||||||||||||||||||||||||||||||||||||||||||||||||
Vendor legal entity kindIndividual, entrepreneur, non-profit company, single-person for-profit, multi-party for-profit | mixedmostly volunteers and temporary contracts via multi-party for-profit merlinux GmbH | cryptocurrency companiesBitfinex, Tether, Hypercore | companyZoom Inc. w | For-profit PLC w | individual | anonymous individual | individuals | team of voluntary developers w | non-profit company | person | ||||||||||||||||||||||||||||||||||||||||||||
Transparency reports | yes w w | no | no | no | no | Transparanty is nonexistentw | ||||||||||||||||||||||||||||||||||||||||||||||||
Vendor jurisdiction | canada w w | Germany w | USA | Canada with two offices in France | British Virgin Islands | USCalifornia w | UK with subsidiaries in France & US | Germany w w | anonymous | Germany w | various countriesincluding Italy, Germany, USA and more w | US | Australiacomplicated 5 eyes jurisdiction with many anti-privacy and anti-encryption laws w | USA w | Depends on the region, but every vendor reports to headquarter in USA | USA w | Switzerland | USA and Cayman Islands offshorexx cMix privacy layer in Los Angeles w | ||||||||||||||||||||||||||||||||||||
Infrastructure jurisdiction | global Tor onion routed network | N/Adepends on provider | Canada | US | Netherlands & Sweden, various for EMS w | N/A | USA | fully self-hosted | globalTor onion routed network | Australia w | USA | USA | USA | USA | Depends on the region, but every vendor reports to headquarter in USA | Switzerland | ||||||||||||||||||||||||||||||||||||||
Infrastructure provider | Tor onion routed network | N/Adepends on provider | Amazon AWSw | Savoir-faire Linux (default) | Amazon AWS | AWS, Cloudflare | N/A | fully self-hosted | Toronion routed network | Hetzner and OVH, distributed Lokinetsession owned servers are primarily hetzner and ovh, lokinet servers are distributed worldwide in multiple countries and with various isps | Sideband uses the peer-to-peer and distributed messaging system LXMF w | Amazon w w GCP (BigTable w ) Fastly w | Amazon w w GCP (BigTable w ) Fastly w | Amazon w w GCP (BigTable w ) Fastly w | Akamai | Amazon, Azure + others | dedicated within data center & unknowndedicated servers within a shared data center for UK/EEA, unknown otherwise | a colocation data center w | ||||||||||||||||||||||||||||||||||||
Good ToSDR gradeyes=A,B, partial=C,D, no=E,F | A w | Dw | no | B w | A w | B w | B w | E w | E w | B w | unrated w w | unrated w | E w | D w | E w | |||||||||||||||||||||||||||||||||||||||
DomainCurrently delegated to the vendor, signals sustainability and commitment, URL including protocol | no | yes w | yes w | yes w | yes w | yes w | yes w | yes w | yes w | yes w | partial w | yes w | yes w w w w | yes w | yes w | yes w w | no | yes w | yes w | yes w w w | yes w | no | yes w | yes w w | ||||||||||||||||||||||||||||||
Reputation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
First releaseyes=mature, large masses have tested it for years, no=only released recently | 2018-01-07? w | 2018-05-09 w | 2022-03-15 w | 2014-03-24 w | 2021-06-25 w | 2017 w w | 2020-06-26? w | 2004-05-21 w | v0.7.0 2022-04-23 w | 2004-12-22 (as SFLphone) w | project 2022-07-25 w w w desktop 2023-02 w | 2015-11-06 w | 2014-08-12 w w | 2018-08-14 w | Feb 24, 2020 w | 2014-03-18 w | 2005-09-02 w | 2020-04-03? w | 2015-05-19 w | 1998-12-31 (as Gaim) w | 2012 w w | 2008-08-27 w | 2022-01-25 w | 2006 w | 2019-07-11 w | 2020-02-06 w | 2022-7-6 w | 2014-07-29 w | 2021-01-14? w | 2018-04-08 w | 2021-05-02 w | 2003-08-29 w | 2011-10-29 originally named "Picaboo" | 2013-08-14 w | 2017-04-18? w | 2012-12 w | 2013 w | 2019-11-05 w | ||||||||||||||||
Public issue trackerWhether outstanding bugs can be viewed by the public. partial=approximated via forum | yes w | yes w w | yes w | yes w w | yes w | yes w w w | yes w | yes w | yes w | yes w | yes w | only for the open componentsw pear://keet/yryskxsgye5j6se8mzzxqoygzion3zyo93iphxhew4pznn7sdbeat17cr5gaquoawe9iq7eipkez99qm6zpkouckg8sacci8bdkgmcdtoc | yes w | yes w | yes w w w | yes w | yes w | yes w | yes w | yes w | yes w | yes w | yes w w | yes w | yes w | yes w | yes w | yes w w | yes w | yes w | yes w w | yes w w w | yes w | yes w w w | no w | yes w | yes w | no | yes w | only in-app reporting via "shake to report" w | yes w | yes w | web only w | yes w w w | w requires registration | yes w w w w w | no w | |||||||
Support teamyes=Dedicated, friendly, sufficient compared to user base | yes | unable to guage lacking public access | friendly but few | partialissues seem to be reacted to, but many requests are rejected w | community wits own forum is offline | no | yes | |||||||||||||||||||||||||||||||||||||||||||||||
No past DDoSno=denial of service happened against vendor operated network | partialThe Tor network, which Briar relies on, is subject to many DDoS attacks. It has mitigated most of them and continues to implement its Vanguard protections ahead of scheduled Tor-core releases. w | partialThe Cwtch application utilizes Tor which has been subject to much stress in the past. | yes | now | DoS using the API for Android and iOS w | |||||||||||||||||||||||||||||||||||||||||||||||||
No past client vulnerabilitiesno=security exploits in client or server side | w w + issue tracker query w | yes wexploitation requires full device compromise, bad actor requires password | 2019 w 2021 w | 2012 w 2021 w | not exploited in the wild w w w w | yes | yesnone published since forking from Signal | 2004-2017 w | remote execution w | not exploited in the wild w w | yes | surreptitious sharing w | many privacy-related hacksw | no w | ||||||||||||||||||||||||||||||||||||||||
No past server vulnerabilitiesno=exploits in self-hostable server or data leaks by vendor | multiple high severity ones w | yes | partial w | yes | no w w | phone number leak w | no w | |||||||||||||||||||||||||||||||||||||||||||||||
No past financing hiccupsno=development can intermittently stop due to lack of funds | noHas 1 backer and no grant since 2018 GSoC, no progress on roadmap, but regular commits w | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Ethical financing in the pastno=tax evasion | yes | yes w | Stripe cryptocurrency, A16Z VC w | yes | noMicrosoft is paying little to no Tax in Scandinavia | |||||||||||||||||||||||||||||||||||||||||||||||||
Ethical business in the pastno=anti-trust investigations, bribes, hurting customers in other way | yes | yes | no | |||||||||||||||||||||||||||||||||||||||||||||||||||
No past conflicts of interestno=shady ownership changes, investor may benefit from breaching privacy or project failure | yes | yes | no | no | ||||||||||||||||||||||||||||||||||||||||||||||||||
No past privacy glitchesno=uncovered cases when vendor secretly exploited user data | yes | yes | yes | no | no w | |||||||||||||||||||||||||||||||||||||||||||||||||
Server hosted untildate of vendor instance discontinuation | 2023-12-31w | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Server development untildate of abandoning maintenance | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Client development untildate of abandoning maintenance | 2024-04-05w | 2022-10-06not officially discontinued, but no new release or post | 2022-08-26not officially discontinued w | |||||||||||||||||||||||||||||||||||||||||||||||||||
WikipediaPasses notability, URL | no | yes w | no | no | no | no | no | no | yes w | yes w | yes w | yes w | no | yes w | no | yes w | no | no | no | no | yes w | no | no | yes w | ||||||||||||||||||||||||||||||
WikidataMay not be reliable due to anonymous edits, URL | no | yes w | no | yes w | yes w | yes w | yes w | no | yes w | yes w | yes w | yes w | Hypercore w Hyperdrive w | yes w | yes w | yes w | no | no | yes w | no | yes w | no | no | yes w | ||||||||||||||||||||||||||||||
ResearchedWhether our research about it has concluded or if it is still fixme-todo | no | no | no | no | no |
Note that it will get lost if you reload this page! You need to copy & paste this manually to share your changes.
You may either open a pull/merge request on GitLab, GitHub or Codeberg or send this snippet over in the Matrix chat room so one of our committers can do that for you.
Please help us fill in the gaps, or contribute new columns or rows to the table. We have a wishlist in order of priority, but you are welcome to contribute whatever interests you.
Chat with us on Matrix:
Chat with us over the relayed XMPP MUC:
Subscribe to the feed of changes via RSS:
The history of the source code repository contains specifics of the individual work done by our past volunteers. We have also tried to outline a summary of who had contributed so far on the following page:
CC-BY-SA applies to data to remain compatible with Wikipedia:
The MIT License applies to software components:
Copyright © 2022-2024 bkil & contributors
Use the **Edit chart** button, click the grid and make some changes.
After you are done, click **Review edits** and copy & paste the content of the box showing the commands with the difference. You have two choices to proceed:
We would like to thank all participants for their contribution. Those listed here have given us a name to attribute to, but we have also received contributions whose authors chose to remain anonymous. Apologies if you have donated time to create value for the project and you are missing - feel free to submit a correction to add yourself. You are also welcome to add your contact information.
new-data, fix-data, review-data, research-data, documentation, build-tools, ui-design, ui-code, moderation, support, boosting
new-data, fix-data, research-data, build-tools, documentation, ui-code, moderation, support, feedback
https://mastodon.social/@mahdi1234
new-data, fix-data, review-data, research-data, operations, moderation, support, boosting
moderation
moderation
fix-data, support, feedback
new-data, moderation
new-data, moderation
moderation, support
fix-data
fix-data
new-data
fix-data
support
new-data
new-data
support, fix-data
fix-data
new-data, fix-data
new-data
feedback
fix-data
fix-data
new-data, documentation
new-data, fix-data, documentation
fix-data
feedback
fix-data
moderation
build-tools, fix-data, moderation
moderation
moderation
moderation
research-data, moderation, support, feedback
https://en.wikipedia.org/wiki/Comparison_of_cross-platform_instant_messaging_clients
https://en.wikipedia.org/wiki/Comparison_of_software_and_protocols_for_distributed_social_networking
https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols
https://en.wikipedia.org/wiki/Comparison_of_VoIP_software
https://en.wikipedia.org/wiki/Comparison_of_user_features_of_messaging_platforms
https://securemessagingapps.com/
English:
https://messenger-matrix.de/messenger-matrix-en.html
German:
https://messenger-matrix.de/messenger-matrix.html
https://securechatguide.org/featuresmatrix.html
https://docs.google.com/spreadsheets/d/1-UlA4-tslROBDS9IqHalWVztqZo7uxlCeKPQ-8uoFOU/htmlview
https://github.com/dessalines/Messaging-Services-Comparison
https://gitlab.com/dessalines/Messaging-Services-Comparison
https://berty.tech/faq#what-are-the-advantages-of-berty-compared-to-the-other-messengers
https://freie-messenger.de/systemvergleich/
https://threema.ch/en/messenger-comparison
https://eylenburg.github.io/im_comparison.htm
https://jayxt.github.io/MessengerComparison/en/
https://github.com/JayXT/MessengerComparison
Q: Can you add messenger "A", etc.?
Each new messenger will add one more column, which will make mobile table browsing experience worse. Presence of more than five messengers will noticably deteriorate desktop browsing experience.
https://wiki.tox.chat/include/clients_features
https://matrix.org/ecosystem/clients/
https://www.privacyguides.org/en/real-time-communication/
The only tabular one that is usable on mobile!
https://divestos.org/index.php?page=messengers
https://secushare.org/comparison
https://secushare.org/features
https://wiki.bitmessage.org/index.php/FAQ#How_does_Bitmessage_compare_to_other_messaging_methods
https://digdeeper.neocities.org/ghost/browsers.html
https://web.archive.org/web/20220511020224/https://tilde.club/~acz/shadow_wiki/browsers.xhtml
Also looks good enough on GitLab as markdown:
CSV columns:
CSV columns:
https://bkil.github.io/openscope-dict-eng-hun/
The summary of a cell should fit at most two lines in a full view. It should only contain links if no details text is present. Further information and links should be pushed off to the details field. This is so that the interactive region of toggling the details and activating a link do not overlap.
Textual review that can not be compared objectively through properties. Links to related technical articles.
Highlight in a few words why it is interesting. Note that this should be our own phrasing for the purpose of consciously differentiating messenger items from each other. It is usually not a good choice to copy some generic advertising text or heading from the homepage of the messenger. Those both lacks context and usually uses wordy marketing & sales pitch language.
List URLs in the details. We can generate a gallery widget from this in the future. See:
Most mobile users will prefer to install through their app store included out of the box.
This facilitates comparing Android API version support and approximate space usage of various messengers. It is only updated once every few months across the whole chart.
See note at "Google Play version".
Alternative phones like KaiStore, Blackberry, OpenStore, PureOS, Microsoft Store
Alternative app stores like Amazon Appstore, Huawei App Gallery, Samsung Galaxy Store, Opera Mobile Store, Aptoide, GetJar, Uptodown, Applivery
See:
See:
The higher the amount of people reachable the better.
List the canonical names of the protocols supported.
Is there some alternative way to start using the service without installing an app? This may be achieved with or without another account through another established app, protocol or platform, such as through a web app, IRC, XMPP, Matrix, the Fediverse or email.
Grammar correction as you type, spelling suggestions, how many languages it covers. Whether it is using the OS default service or reimplements it in some way.
Whether they are persistent between restarts, chat log, file transfer, inline images, offline messaging
Audio, video
Ideally push to talk, may be useful where voice call is not supported. Also voice notes
Whether multiple participants can share their screen or only one at a time.
Noise cancellation, gain control, voice activity detection
Retry, pause, resume, file size or type limit.
Font size, bold, italic, underline, strike-through, list, blockquote, code, pre, colors, clickable link, table, subscript, superscript, line break, horizontal rule
Deprecated. Please do not fill in this property for new messenger items. Work towards refactoring existing cells into the below new properties instead and then empty this cell. (Was: Compose, show)
Whether they are animated. Where is it stored, at each individual or is it available group-wide?
Unfurling: who downloads the page, the sender, the recipient or the server of one or the other
Supported image formats: png, jpeg, gif, webp, avif
Supported video formats: mp4, webm, av1
Multiple choice voting. How seamless is its integration to the client interface: is it more like a bot that you need to converse with or can you click on buttons.
Provides free tasting to look around before committing to install anything or having to remember another pair of credentials. See:
If the same account can be used at the same time from multiple devices, syncing contacts, messages and notifications.
If the user lost all of their devices, can they continue from where they left off after purchasing a new one and at most by typing in a password? Manually cloning the internal storage of the device externally every day and restoring it on a new one is expected to produce a similar result, except if the app locks itself down via DRM (hardware credential store, eSIM, serial number, etc.). Hence, concentrate on features of the messenger that makes full restoration possible without such external manual workarounds.
If you can stay logged in with multiple accounts on the same device and application without external isolation techniques. Notifications shouldn't interfere either.
Unlock the account or certain chats with a PIN code, passphrase or biometrics such as (fingerprints or facial likeness)
Also called redaction, retraction or deletion. Used if you sent the message to the wrong chat, to hide stale information or by moderators to hide spam from others so as few will have to read it as possible.
Note: An adversary can always use the analog loophole of taking photographs of the display. Hence, we can assume that such a feature caters to cooperative peers.
Also called editing. The main use case is to fix typos or to better summarize stale information resulting from further discussion if later comments invalidate some of the former ones.
See the note at remote message removal.
Also called retention time, disappearing/ephemeral/self-destructing messages. The main use case is to keep your chat log clean, to publish limited time offers or requests and to help maintain as few copies of sensitive information as possible on the long term.
See the note at remote message removal.
Whether it is supported and how many levels can be differentiated. A user may signal towards another whether they are online (available for chat) or offline (busy, away, do not disturb, hidden, stealth, custom status message).
Presence of another user may be shown within either direct messages or group chats.
If it has presence broadcasting, can you hide the fact that you are online from another user?
Tinfoil persona may consider it a threat to anonymity if one can log behavior patterns of another such as what time of day the user is connected to the network, travelling, attend classes or what custom messages they are using. They may correlate such activities across accounts.
A messenger may not allow the user to override presence, instead substituting it with recent activity based status detection. The messenger could independently provide for scheduled or bot based authorized message delivery delegation, so such an option may still provide for privacy advantages.
This can also provide for improvement to quality of life and work-life balance of a layperson. One could for example allocate 30 minutes of active chat time in front of their device when they initiate conversation and another 30 minutes where they switch their status to "do not disturb". The latter would provide an opportunity to reply to any new incoming message about topics being followed while signalling to all peers that they would prefer not to engage in further requests until the next working day.
Whether sending and showing is supported. Mention in the explanation whether it can be disabled and its default state.
Whether sending and showing is supported.
Appearance, dark scheme, night mode, OLED, prefers contrast, reduced motion, color blind, custom base color, large fonts, visual style presets, automatic switching
Introductory website maintained by vendor, may use SaaS subdomain, URL
Knowledge base maintained by the vendor, user manual, tutorial, extensive FAQ, URL
Otherwise users need to moderate their content themselves based on peer to peer power structures.
If it gained worldwide adoption
Solvable with centralized or federated servers or with revocation certificates in P2P.
Solvable with centralized or federated servers or with subkeys, revocation and secret sharing in P2P.
Ensure that device wakes up as few times as possible, filters and batches events on the remote side, no sockets kept open indefinitely, delegated peer tracking
Conservation by lazy loading, previews, adaptive detail, incremental sync, fewer round trips, tokenization, batching transfers to improve compression, tweaked key schedule, multicasting hubs
Avatar, prefer FOSS, externally hosted, Wikimedia URL
This is more important for closed or non-self hosted servers. See:
Regardless of this, certain OS vendors might also have access to your keys
Deny sending a message, repudiability
Of third party buffering nodes
Mitigation against downgrade attacks
If the client never sends over its contact list to the server
yes=regularly scanning for vulnerabilities proactively, found bugs inspected for security implications, partial=reported vulnerabilities promptly fixed and released
yes=it is clear how the project can operate indefinitely, no=we know nothing, partial=public statements were made but not convincing
It can be deployed on-premise in a LAN without internet
Improving the scaling of the system and communicate with anyone (i.e., if P2P or federated)
Will the system still work if the developer goes bankrupt
Copyleft, editable by users through a wiki or source code repository, URL
Publicly readable, URL
It is a web site (web page) accessible through the Internet using a web browser without having to install special software or register an account. Both potential and existing users can ask questions here about the item and answer topics of one another. It should have a search facility to find FAQ without having to ask the same things all over again. Web search engines and archives must be able to index it. This would provide a nudge to use the given system.
Common examples of backends include phpBB, FluxBB, Discourse, Friendica, Hubzilla, Lemmy, mailing lists, NNTP, CMS comment threads. Further CMS-based alternatives would be possible to implement.
You can access and search a mailing list archive from a web browser. Even netcat could suffice if the page is frugal, such as in case of Mailman 2. However, we can assume that a user will possess at least Netscape 2.0 or a gemiweb0 browser or implement it themselves if they want to read such web pages.
In contrast, a community group chat room accessible over the given messenger protocol, even if it provides for limited chat log, usually does not qualify as `Web forum`, but rather as a `Contact` method.
URI including the scheme prefix, preferably of official group chat, such as matrix: acct: xmpp: msrp: news: mailto: irc: sip: mumble: ssh:
URL of RSS, Atom, twtxt or gemini text feed
List all server software or instance by name that are mandatory to keep this network running or to host it in isolation
List all server software or instance by name that can provide extra features when using this network
If communicating over the internet might scale without (a vast amount of) dedicated servers, i.e. by supernode promotion and DHT. See:
If you can communicate without an internet connection and a server. See:
You can compose messages to your peer even if the two of you aren't online at the same time
Built-in support for peering with nearby nodes over ISM wireless either to sync or as part of a mesh. See:
See:
HTTP, Tor, SOCKS5
See:
Apps, widgets, integrations by third party developers or users themselves
Optionally provided so that a user need not maintain a separate server
See:
Still green if only registration is limited to IPv4
If it is illegal or blocked here or if the vendor prohibits usage or its infrastructure blocks users from here. Encryption itself is outlawed in many countries, do not list these.
Individual, entrepreneur, non-profit company, single-person for-profit, multi-party for-profit
Currently delegated to the vendor, signals sustainability and commitment, URL including protocol
yes=Dedicated, friendly, sufficient compared to user base
no=denial of service happened against vendor operated network
no=security exploits in client or server side
no=exploits in self-hostable server or data leaks by vendor
no=development can intermittently stop due to lack of funds
no=tax evasion
no=anti-trust investigations, bribes, hurting customers in other way
no=shady ownership changes, investor may benefit from breaching privacy or project failure
no=uncovered cases when vendor secretly exploited user data
date of vendor instance discontinuation
date of abandoning maintenance
date of abandoning maintenance
Passes notability, URL
May not be reliable due to anonymous edits, URL
The picture should ideally be lossless PNG or WEBP. Keep it small by not showing much true color content if possible.
You should ideally submit a pull request in the repository of the respective software if you need to add a screenshot. It could reach their website and their app stores as well.
Wikimedia Commons (Wikipedia):
F-droid:
Mirrors:
(on demand: Codeberg)
If you would like to show mock user generated content on the screen within discussions, it is best to choose public domain material:
https://en.wikipedia.org/wiki/STRIDE_%28security%29
Some of these may be investigated in the future by volunteers. Others may be added to a list that list legacy or scam alternatives or may be discounted.
Here are some ideas regarding new aspects to research, feel free to factor these to atomic property definitions or suggest more:
Here are some properties we have investigated and deemed redundant or to not be worth our time (at least while the rest of the table is empty):
https://en.wikipedia.org/wiki/Social_networking_service#Definition
Bootstrapping is a critical problem with any similar project. IPFS ships with a hardcoded list of servers:
They are probably financed and operated by the project owners. Such a VPS usually costs quite a lot of money, but I haven't checked the exact specs.
The documentation does list the IPv4 address of one node, but refers to most through a domain name. The (single) domain name is probably hardcoded in many places and they also have to pay for that and operate a name resolver as well, increasing the number of bottlenecks from 1 to 3: bootstrap.libp2p.io
Most of the world might have trouble reaching IPFS because it is not very good with traversing NAT:
The workarounds might be good enough for those fortunate enough to be able to forward ports, but those could already just as well run a normal FTP/SFTP/Synching/rsync server for the same effort.
It probably solves various problems pretty well, like synchronization between your data centers or creating virtual clouds this way, but it is hardly what will solve the problem of decentralizing computation to the hardware of users if it gained worldwide traction.
Comparing BitTorrent, IPFS, Secure Scuttlebutt and Hypercore (Dat)
A PC is a platform where:
Drawbacks (compared to F-droid):
Google advantages:
If you are using an out of date version of a mobile OS, because perhaps the vendor did not produce as update for you, you may still be affected by some of these.
This could also be interpreted as a flaw within each vulnerable application itself as well.
"Surreptitious Sharing" Android API Flaw Leaks Data, Private Keys: vulnerability in messaging apps [using the API] like Skype and perhaps Signal, and Telegram, that could lead to privilege escalation and data loss, including private keys. The attackers were able to get Threema, and another encrypted messaging app, Signal, to share its database as an audio recording. The researchers claim they were able to retrieve the file, save it, and open it as a database file. The two claim Signal was vulnerable - chiefly because of the way it processed the file - and crashed for them on each start.
Over The Air: Exploiting Broadcom's Wi-Fi Stack (Part 2)
Over The Air - Vol. 2, Pt. 3: Exploiting The Wi-Fi Stack on Apple Devices
In this blog post we'll complete our goal of achieving remote kernel code execution on the iPhone 7, by means of Wi-Fi communication alone.
Posted by Gal Beniamini, Project Zero
Kryptowire Identifies Security and Privacy Vulnerability in Mobile Device Chipset from China [...] allows malicious actors to take control over user data and device functionality.
found a vulnerability which can be used to disrupt the device's radio communication through a malformed packet.
Protecting yourself:
Helping how to define your own "threat model":
TL;DR Their servers = their rules
If you (=the user) use the telecommunication service (=the service) provided by a given legal entity or natural person (=the provider), a legal contract is made between the user and the provider.
Courts accept various forms of consent when agreeing to a contract:
The provider has legal basis for restricting in what ways the user may access the service.
No further elaboration would be needed, but let me share a few technical insights into why it is desirable for the provider to restrict alternative access methods (e.g., a third party client):
How decentralized is Tor? Is it serverless? Can it continue to operate when its principal vendor loses interest? Can it stay operational without any financing at all?
If you use Tor or an app uses it under the hood, it first connects to 10 servers called "Directory authority nodes" to get a node list. Their IP address are hard coded in the application. They are probably ran by the Tor Foundation.
It then discovers the address of relay servers operated by select volunteers from the public Tor directory and attempts to connect to some of those.
If you are using proxies or bridges, you are using even more intermediate servers:
If your destination lies outside the Tor network, you will also have to discover and utilize exit relays.
The general latency, low offered bandwidth and the constant changing of the network topology also makes supporting voice/video calls unfeasible.
The directory authority nodes can be interpreted to form a centralized high-availability core.
Tor relays and exit nodes can be interpreted to be forming a closed internal federation whose services can be utilized without registration. The admittance of their operators is subject to undisclosed criteria of curation by the foundation and automated monitoring.
Not all nodes are equally privileged. Your messenger is only a Tor client, while volunteers or funding is needed to run Tor relays (and other Tor servers) around the globe to keep it running. This separation precludes automatic scaling of the system by growing capacity along with an increasing user base of the client.
Let's trivialize the traffic flowing towards the directory servers. The traffic volume flowing towards the few relays and exits is huge and is amplified sixfold by forming circuits. This means that there exist built-in limiting cost centers - bandwidth choke points not correlated with how many people install the messenger clients themselves.
Was threat actor KAX17 de-anonymizing the Tor network?
Thirteen Years of Tor Attacks
It is possible to detect and block Tor/VPN users either by the target website or the ISP.
If you intersperse your clearnet vs. Tor/VPN access patterns, one with a bird's eye view can actually correlate it pretty easily (i.e., state actors and funded malicious organizations). If you are using certain sites for longer stretches or even register on some, this can even be achieved purely with local inference.
You place ultimate trust in what a VPN provider says because there is no way to verify it, except after the fact if they were exploited. You can't influence whether they use encryption or turn off logging for example.
In case of going through a VPN, your local ISP can still log the timing & size metadata of packets (along with DNS, NTP and other leaking things if not set up correctly on any of your nodes). The ISP of the VPN provider can also log (and MITM) everything that could have been logged in the first place.
At least with your local ISP, you have a signed contract and you kind of know who they are (usually a local company), whereas in case of a VPN provider, they are almost always the NSA. You also support the local economy by using local services instead of foreign ones.
- http://tilde.club/wiki/vpnwhy.html
DON'T USE VPN SERVICES. Why not?
No, seriously, don't. You're probably reading this because you've asked what VPN service to use, and this is the answer.
VPN servers seized by Ukrainian authorities weren't encrypted
On the disk of those two servers was an OpenVPN server certificate and its private key [...] the company also uses data compression to improve network performance. [...] an attack known as Voracle, [...] uses clues left behind in compression to decrypt data protected by OpenVPN-based VPNs
- https://vice.com/en/article/jg84yy/data-brokers-netflow-data-team-cymru
How Data Brokers Sell Access to the Backbone of the Internet.
ISPs are quietly distributing "netflow" data that can, among other things, trace traffic through VPNs.
- https://twitter.com/josephmenn/status/1437885720169836544
The at least until recently CIO of big VPN ExpressVPN is one of the three former U.S. intelligence operatives who agreed today not to fight charges they illegally helped UAE hack people. Kind of makes you think.
New research reveals Surfshark, TurboVPN, VyprVPN are installing risky root certificates - TechRadar
Security design flaw paves the way for surveillance or man-in-the-middle attacks
Beware that this whole article is work in progress with parts missing, parts needing rewording and parts needing integration from uncommitted local changes!
A disclaimer is justified for so called "encrypted mailbox providers" in general. Emails are routed basically as clear text around the world and can also be assumed to be stored as such on most nodes. It does not enhance your privacy guarantees sufficiently if the online mailbox provider promises to encrypt individual emails before storing them. Such providers have confessed to opting to deactivate their protections multiple times in the past.
Various articles attempt to generalize this claim and phrase it as if web browser based applications lacked certain security guarantees or as if theoretical basis precluded us from developing secure web apps. Let's try to investigate these claims in detail.
Do not use webapps in zero-trust designs
Let's assume that all else is equal: both the desktop app and the web app are FOSS.
A common claim is that the vendor could alter the code for the interface any day without the user having control or even noticing.
It is commonly mentioned that installing software from reputable third party distribution channels independent from the software vendor should guarantee accountability. Examples include the package manager of the Linux distribution or the Windows Store.
Web app distribution platforms also exist of equivalent functionality, such as the Chrome browser market, typically promoted for web extensions or userscripts.
In certain cases, people install apps from software repositories controlled by the software vendor or a party not affiliated with the OS vendor, such as:
The security guarantees are all similar in the above cases. In an arrangement so called "TOFU" (trust on first use), the user verifies the fingerprint of the repository, website or the initial download and does a cross check on it to make sure it is authentic. Afterwards, assuming it is a FOSS reproducible build and has been reviewed, certain blatant intentional backdoors could be dismissed, assuming the check of signatures is implemented properly during updating.
An automated mechanism set up on our device usually checks for and installs software updates found in the vendor repository, especially if it is marked as a security fix. Such checks may happen daily.
The vendor has in most of these cases a means to provide packages with different content to certain targeted subsets of users in a "bait and switch" scheme and possibly switch it back afterwards before detection.
This would apply to any platform, including web, desktop and native mobile apps that support daily updating through its own servers or stores.
When inspecting onboarding workflows at a big tech company in the knows, I have seen how many third party (mostly FOSS) stuff one needs to install on a Windows or Apple computer by hand by visiting dozens of websites, clicking download, install, next, next... This includes Homebrew, but most things were not available from there. Assume a dozen other things were needed as well as a daily driver. This was part of an initial setup process of individuals entrusted with management of their gear. On Linux set up just for secretaries without admin privileges, the sysadmin would surely just clone an image on all hardware and be done with it.
As you visit these dozens of websites to download your installers, you are initiating TOFU (trust on first use). It assumes the same level of trust as installing ("visiting") a modern web app built on a Service Worker from the same domain. The alternative to TOFU would be to meet the developer in person or exchanged a business card containing a QR code with their certificate.
Incidentally, I have seen another company where these exact same installers were already downloaded by an sysadmin and supplied over a local network share. However, it provides little help
With most Linux distributions, if you aren't looking for some very specialized tool or a trunk version of something, you could get away with just installing everything from the official package manager. This places all trust on your distribution, so it is a different scenario, but not all people have this luxury depending on their occupation.
HTML markup in email is severely restricted since the last decades. They can't run JavaScript. It can't even apply most parts of HTML or CSS freely either, but only a strict subset that varies by client.
They mention some simple workarounds except Service Workers.
It is possible to implement a FOSS webapp which
A webapp can be implemented in a way so as that the offline part (for example, within a Service Worker) is only ran once, and only pulls in additional resources using SRI or after checking their cryptographic signature (in case of updates). This places trust equivalent to installing a desktop software package from the website of a vendor. The same could have been implemented in various other (more twisted) ways even decades ago, but I better not go into that here.
Web (-Browser based) Apps, especially if FOSS and engineered from the grounds up for offline use via Service Workers, are for most intents and purposes isomorphic to non-browser based apps. It's just another containerization technology and runtime.
It is equivalent to saying that the software vendor of the mobile app or desktop app is untrusted in the exactly same way, along with its update mechanism.
At the same time, nothing keeps you from self-hosting the web apps you use either on a trusted server or even on localhost and review all code changes before running them.
It is unfortunate that very few good and complicated webapps are FOSS or support separation of frontend & backend properly. Being able to self-host Element Web while using an outside Synapse is a rare pattern.
Programming errors occur frequently in native apps as well (be it email or other messengers) - it is not tied to E2EE web apps. I.e., RetroShare also had a critical remote code execution just recently and it is written in C++ (a language with manual memory management), not JavaScript.
Compose a email to any protonmaail user with Subject:
#"><img src=x onerror=prompt(1);>Send email to victim
How to accidentally find a XSS in ProtonMail iOS app
$body = "<html><head>"$body += "<title>test</title></head>"
$body += "test`">`'><i>I</script><script>alert(1)</script>testscript</i>"
$body += "</body></html>"`
And neither one was HTML email - they were just plain text!
Vid shows how to easily hack 'anti-spy' webmail (sorry, ProtonMail)
Filtering evil JavaScript is tricky if you're encrypting in the browser
"P2P" is ill defined, thus we discuss its conflicting meanings separately:
Where did the term "P2P" originate from?
Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or workloads between peers. Peers are equally privileged, equipotent participants in the network. [...] The architecture was popularized by the file sharing system Napster, originally released in 1999.
Basically in the 90s, you could find centralized file hosts (FTP, BBS) where people would upload their wares from where others could later download them. Then came a new model where everyone could store their wares on premise and others could access it directly without having to upload/download to such centralized hosts and that was called P2P file sharing. So the term originates from a specific type of distributed storage where instead of operating centralized nodes with costly spacious HDDs and paying an arm and a leg for bandwidth costs, their specs could be greatly reduced by allowing peers (who either have or want the files) to chime in.
The original intention of messaging projects which variously advertise themselves with loosely related terms such as "P2P", decentralized, distributed, federated, independent, blockchain-based, serverless was possibly of related nature: to allow a new competitor in the messaging apps space to enter without a huge investment. Just look at how many millions of dollars operation of the centralized Signal (or the matrix.org home server) costs.
Applying the term to messengers is not trivial and I think it should be avoided if possible, especially as cryptocurrency scammers started using this label for their marketing efforts. However, I would say that such messengers would apply a network topology that minimizes the use of centralized nodes which could pose as bottlenecks or cost centers and should do as much computing on the edge nodes (the device within your hand) as feasible to enable this. The sustained growth of capacity would thus be ensured by the growth of the user base.
This also sounds to be in line with the spirit of unhosted web apps.
Some misleadingly advertise themselves for enhanced anonymity and privacy. For such, the only scalable architecture proven so far was similar to centrally operated mixnet-based email remailers from the 90s (also loosely inspiring the similarly centrally operated Tor network). None of these are resistant to censorship either, despite what various advertising campaigns wants us to believe.
One can ask whether each client gets to "keep" a copy of their own UGC (friends, messages, attachments) as if they had an complete backup or profile take-out updated in real time. Or if instead a user blindly entrusts such storage duties to the vendor to then access it piecewise later on, possibly resulting in total data loss if anything happens to the vendor?
Some think that "P2P messengers" should provide for pure anarchism as in not relying on any third party hosted infrastructure or vendor human resources at all, but this can be refuted extensively.
Why should you not enable E2EE in public rooms? Some of these reasons are specific to the current implementation of Matrix servers and clients, while others are more general in nature.
Main article:
Such projects advertise many use cases that would otherwise be better served with another technology.
For high density and short range use (a few hundred meters), see:
Caveats:
Existing alternatives:
See also:
As a better alternative, licensed hardware amateurs with the required radio operator skills within each local community could bridge longer distances:
They could keep in touch with the local community using messengers supporting unlicensed wireless ad-hoc mesh, delay tolerant networking or 1-on-1 syncing using standard hardware.
Their position and contacts could be shared on an offline map.
Main article:
Hosting servers within a LAN or building small meshes could still make sense, for example in the context of a large housing complex or even a dense village district. If everyone within a 500m range has the same power source, you could mind as well assume that they could either all have LAN or neither of you would. And at least you could play LAN games with your neighbors, along with syncing your mobile DTN mirrors especially if you commute to school or work.
Main article:
You only have a direct connection between two clients if they are:
LoRa is not very spectral efficient given high density
A mesh necessitates having a certain amount of nodes online to maintain a spanning tree. This will be problematic when power & communications links go down in certain towns.
On the other hand, if you focused more on gossip & opportunistic replication and building F2F based on real world web of trust, information could spread much better. This is something that every network gets wrong that is developed in the first world as a "hobby" (or via grant, VC, crowdfunding, etc).
This started as a joke, but pigeons can actually be thought to complete two round trips per day autonomously by placing their food up to 160 km away from their nest.
If coupled with either low tech monitoring of their arrival or wireless sync and charging and a constant and planned stream of backup birds and hardware, it could provide a commercially viable decentralized alternative to erecting and maintaining expensive relay sites over long distances.
It would be feasible to implement a hybrid P2P/F2F system where as much roles would be delegated to supernodes and friends as possible and the only remaining duty of the central server would be to sign new releases & the peer database pyramid before they get injected to the P2P storage network. I postulate that you could serve the whole world from even a VPS costing a few dollars (or a free PaaS even) if implemented right.
Parent article:
As an empirical data point about such a development project, consider how Torrent was adapted to WebRTC as WebTorrent. It is a use case that was much more desirable for users. PeerTube is also built on top of it. However:
Now consider doing something like this to another well known protocol, like Tor, I2P, Freenet, GNUnet, Secure Scuttlebutt or Dat.
Some of the privacy-focused overlay routing networks also provide too low bandwidth, too high latency, setup latency or regular circuit switching to be comfortable for live voice & video calling and many use cases for screen sharing. See also:
Basically what would be a big win if the application was continuously updated within its distribution media (either daily within the app market or possibly minute by minute if you download the package from its own web site or repository). It's just a CSV that needs to be updated (and resigned) within the bundle.
For example, as the package for pybitmessages hasn't seen an update since 2018 (and most similar apps are rarely updated more than once every few months and usually manually), such a dynamic list would not work except for listing the mostly-on nodes possibly added manually (that incidentally Tox is also doing, but they admit that it's not enough). CI/CD has been a thing for decades now, so it's kind of appalling to see that few FOSS projects are doing it to this day.
See the Peer Exchange BitTorrent extension:
http://bittorrent.org/beps/bep_0011.html
It might be feasible to infrequently scan neighboring IPs for possible peers on well known ports. Many ISPs already assign IP ranges in a kind of cartographic locality, so it would provide low latency paths automatically if you scanned in increasing distance from your own WAN IP (and/or its "aliases" over the virtual allocation range). This would only be feasible if a sizable proportion of the population would have it installed, let's say 1%, otherwise it's considered spamming.
See the Local Service Discovery BitTorrent extension:
https://www.bittorrent.org/beps/bep_0014.html
A rendezvous server helps peers find each other by exchanging introductions, facilitating peer event signalling or hosting pointer invitations. It should be publicly reachable. It need not be a full blown complicated peer node itself.
A mostly static web server with a few lines of PHP or CGI could suffice. You could substitute various preexisting technologies, for example public DNS records (or even free dynamic DNS), git repository, static web hosting of each member that can be updated through an API.
A custom rendezvous server could also be replaced by a bot connecting to some other popular available server, whatever is common within a given community: a mailing list, forum, matrix chat, bulletin board, whatever you and at least some of your friends already have access to. Lacking that, you could sometimes even run a tiny dedicated server piggybacked onto some other system, as in:
https://gitlab.com/bkil/freedom-fighters/-/blob/master/hu/service/game-backend.md
See also the Holepunch BitTorrent extension:
https://www.bittorrent.org/beps/bep_0055.html
It could also be implemented as a supernode feature - built into the default client so nodes with publicly routable address could volunteer automatically.
Existing messengers advertised as P2P always use a supporting underlying network of dedicated servers that are pretty expensive to maintain, hence why 90% of the new alternatives that pop up always involve a cryptocurrency for monetization.
F2F would be an alternative as a way for users to maintain reputation among each other and to refrain from committing abuse without consequences.
Consider that if you only ever link to your friends directly and you trust them, metadata collection (it terms of keeping logs or deleting expired or retracted messages according to gentleman's agreement) wouldn't be an issue at all.
It could be useful for:
In the framework of WebRTC/ICE, STUN & TURN are used together, because STUN itself can only connect a subset of nodes (up to 90%, but it's much worse among mobiles). And bandwidth (CPU?) costs at TURN relays can be quite significant, hence why it is a central point of failure.
But nothing would keep a hypothetical real P2P network from building up a spanning tree via F2F to forward packets and distribute routes among static volunteers and/or dynamically established pairs. And STUN/TURN is kind of an anonymous, stateless service. With global deployment, it needs either funding, or credentials to access it and/or F2F authorization. It also requires an independent signalling path via which you forward peer invites, and that is also usually some kind of central server on presently implemented systems.
Skype did it decades ago with automatic super node promotion, but I have yet to find another messenger (or data sync or social networking service solution) that is capable of anything like that.
The basic design flaw of many messengers is that the only way to reach users who are not publicly routable is through relays, and only a few nodes are TCP relays (optional setting) a lot like if it went over TURN. Rather, this should be the default (and detected during runtime even), and it should be modelled after ICE - select between STUN alternatives and only resort to something like TURN if there is no solution otherwise. This would reduce the load on relays tenfold at least.
I think solving store & forward in a decentralized system is best done through a friend-to-friend topology. I.e., not only your own devices store your messages, but also some owned by your circles. And having to run a separate 24/7 mailbox/relay hardware peripheral isn't going to cut it either (what about e-waste and wasting power - see why shared hosting is the best for the world)
See the following for sources of inspiration (copying is not allowed except the license-compatible Wikipedia and we need references to each cell value anyway)
The project closed down in 2019.
A look at how private messengers handle key changes
Remarks about code quality and comment thread.
Berty Messenger for iOS and Android - Zero Trust Open Source Peer-to-Peer Messenger based on IPFS protocol
https://chican3ry.medium.com/ergonomics-are-a-security-issue-some-notes-on-briar-8ae36be29335
I am not online all the time, I only connect some times, receive all the messages maybe reply some and go offline again, to save battery and mobile data (btw, briar is heavy for battery and mobile data so I was not even able to have it running all the time, it was draining my data plan) other contacts that are in my same situation will not be online all the time so the chance we are both online at the same time is low, but anyway none of my contacts use Briar, they delete it immediately pretty scared and annoyed "hey!!! that crap drained my data plan!!!)
Do Briar and Jami use a lot of background/idle data?
like hell, I had to uninstall them
I have restarted the app, now I see you
Cwrch is not stable and hard to work with. For p2p, briar and anonymous messenger are more stable for me.
Your last messages on Cwtch didn't arrive for me, it is really unstable
I can only confirm what was said on 2022-03-03. Tested two phones + desktop. Pairing them together was quite a nightmare. After pairing, some messages never arrived. Or got notifications, but no messages delivered. Group was possible to create from desktop only (not sure why), but I could invite mobile clients, which was another pita experience. Only one of the mobiles eventually joined group and a day later was able to finally exchange some group messages.
FBI Document Says the Feds Can Get Your WhatsApp Data - in Real Time
A previously unreported FBI document obtained by Rolling Stone reveals that "private" messaging apps WhatsApp and iMessage are deeply vulnerable to law-enforcement searches
FaceTime Privacy & security guide
Well, despite I like Jami, it has flaws. Not syncing messages, draining your battery, etc etc.
Do Briar and Jami use a lot of background/idle data?
like hell, I had to uninstall them
https://joshua-m-david.github.io/jerichoencryption/index.html
Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin - John von Neumann
I see that it uses file image data or freshly taken pictures as its source of random numbers:
This uses the underlying thermal noise of a CMOS sensor, however its weakness lies in that it does not account for biases due to defects in the sensor or dust, and an even bigger issue is image enhancement artifacts introduced by post processing of the camera driver or firmware and that the demosaicing algorithms themselves introduce elaborate correlation within the bits (i.e, to interpolate the missing information).
It falls back to Salsa20 on failure:
After scrolling through the source, I say that it is mostly well engineered. However, it contains tens of thousands of lines of code and additional external algorithms. Reviewing that is not implausible for a dedicated researcher given a weekend, but this would not be sufficient for a careful review. Doing that would be awkward because its test coverage and modularization is not that great in that aspect. And based on the sheer number of lines, I would bet that it has quite a number of technical flaws.
And then it also misses the opportunity to use more modern technologies (like Haxe, TypeScript and SCSS).
Overall, this project also just reiterates what we know of OTP vs. stretching based encryption: OTP is theoretically superior, but managing and communicating the huge key material itself is awkward _(all the extra chores to authenticate the key material in the database is just unproductive for example)_. Compare this to just a few lines of code to use the Web Crypto API or some other well known built-in encryption primitive:
https://matrix.org/ecosystem/clients/
This section was migrated to #public_room_e2ee
Megolm group ratchet: Partial Forward Secrecy
XMPP with OMEMO is similar to Matrix MEGOLM for E2EE
Why are large public rooms not encrypted?
We should not copy & paste each and every blog post they broadcast, but may want to link to things that are frequently asked.
Are We P2P Yet?
Matrix metadata leaks
Matrix? No, thanks.
Privacy research on Matrix.org
Notes on privacy and data collection of Matrix.org
Reasoning Why Disroot went back to XMPP in 2018:
Matrix Closure
Matrix notes - anarcat
Aminda
https://web.archive.org/web/20230602104826/https://dimension.sh/~novaburst/ac3bf733.htm
Matrix - The Mossad Facade that fooled the privacy community
Replies:
German states of Schleswig-Holstein and Hamburg deploy a Matrix-based solution for 500,000 users across public offices and education
Bundeswehr developed Bwmessenger, a chat service that's built on Matrix's software, and 50,000 from the force are now using the service.
What are XMPP and Matrix and what makes them special?
XMPP vs. Matrix
Ein Fehler in der Matrix (German lawyer regarding GDPR compliance)
Populus-Viewer is a tool for decentralized social annotation, built on pdfjs, wavesurfer.js and the Matrix protocol. You can use it to read PDFs, listen to audio, or watch videos, and have rich discussions in the margins, with your friends, classmates, or scholarly collaborators.
A privacy focused social media based on Matrix
Matrix-CRDT enables you to use Matrix as a backend for distributed, real-time collaborative web applications that sync automatically. The MatrixProvider is a sync provider for Yjs, a proven, high performance CRDT implementation.
2014-08-12 Synapse server v0.1 with integrated webclient (+48k SLOC imported from unknown source):
It debuted with a `Twisted>=14.0.0` dependency that was released on 2014-05-12
2014-09-03 Public announcement:
2014-09-30 Riot Android SDK:
2015-06-02 Riot Android, probably forked from the Android SDK (+14k SLOC imported)
2015-06-09 Riot Web (React JS SDK):
2016-06-09 Vector (Android)
2018-01-29 $5M investment by Jarrad Hope's Status:
to expand its team significantly over the course of 2018 and continue development of both the Matrix protocol and improving the Riot.im client
create a bridge between Matrix and Whisper - Ethereum's own real-time communication protocol - and allow Status dApps to be integrated as widgets within Riot.im. It also allows the Status Network token to be used, enabling cryptocurrency payment mechanisms in Riot.im.
Status migrated its community from Slack to Riot.im last year,
2019-10-10 $8.5M investment by Notion Capital, Dawn Capital and European seed fund Firstminute Capital:
improving the user experience in Riot for the app to be, as Hodgson puts it, "properly mainstream" - aka: "a genuine alternative to WhatsApp and Slack for groups who need secure communication which is entirely within their control, rather than run by Facebook or Slack".
they'll be turning on end-to-end encryption by default for all private conversations.
building out their flagship Matrix hosting platform (Modular.im) and building it into Riot - "so that groups of users can easily hop onto their own self-sovereign servers".
they intend to work on combating abuse [...] the question of how you moderate hateful communications could easily get overlooked.
2020-05-21 $5M investment by Automattic (WordPress.com)
Automattic just opened up a role for a Matrix.org/WordPress Integrations Engineer
we should expect to see Automattic's communities migrating over to Matrix in the coming months
Imagine if every WP site automatically came with its own Matrix room or community?
Imagine if all content in WP automatically was published into Matrix as well as the Web?
Imagine there was an excellent Matrix client available as a WordPress plugin for embedding realtime chat into your site?
Imagine if Tumblr became decentralised!?
2021-07-27 $30M investment by Protocol Labs and Metaplanet (Jaan Tallinn of Skype and Kazaa):
transforming the Element app
finish building out P2P Matrix and get it live (including finishing Dendrite)
implement native decentralised E2EE voip/video conferencing for Matrix
fully build out our relative decentralised reputation system in order to combat abuse in Matrix.
getting Spaces out of beta
adding Threading to Element
speeding up room joins over federation
creating 'sync v3' to lazy-load all content and make the API super-snappy
lots of little long-overdue fun bits and pieces (yes, custom emoji, we're looking at you).
Amount of cryptocurrency donations:
Financial statements of company:
https://www.olvid.io/assets/documents/2020-12-15_Olvid-specifications.pdf
Olvid does not have a built-in tracker but in the Android version of Olvid and only in it, what is detected as OpenTelemetry by the app analysis tools is in fact an OpenCensus library which is a dependency of the Google Drive connection library. Olvid doesn't bring up any telemetry data, but some components of the library are used for communications with Google Drive, including automatic cloud backup with Google Drive, as described here. So: Olvid cannot remove the dependency as long as Olvid provides the ability to do automatic cloud backups with Google Drive, as described here. If you do not enable automatic cloud backups with Google Drive, no lines of code from this library will be executed within Olvid. If you enable automatic backups to the cloud with Google Drive, some lines of code from this library will be used, but not for telemetry data retrieval.
A Review of Lokinet (Oxen): A Road to Nowhere?
Technology preview: Private contact discovery for Signal
It details two alternatives:
The Difficulty Of Private Contact Discovery
From that overview of possible implementation alternatives, but somehow discounted encrypted bloom filters citing concerns about bandwidth costs.
However, that would have actually worked perfectly if they updated the set on demand when checking for a new contact number and/or if the database was synced P2P via WebRTC to reduce their bandwidth costs.
And also, as I think 99% of the users only have domestic contacts, sharding by region might actually work.
As such contact discovery can be pretty hard on the server side, federated servers would be great to have here as well.
Note that secure, zero-knowledge contact discovery can be an issue for any alternative system even if it used some other identifier, like an email address (or matrix ID, Friendica profile URL, etc.
Stepping back from a theoretically sound solution to one where you must trust a vendor that also happens to have a sketchy safety record is dubious at best.
The storage service and the key backup (which must be hosted in GCP) relies on CDN0 S3 (for uploads of user profile, group v2 avatar, attachment v2 with attributes, stickers) and CDN2 GCS (for uploads of attachments):
All components for abuse control:
SGX CDSI (the HSM CDSH development version does have source):
Web service for handling pushing and serving updates.
Scripts and recipes for devops to deploy and monitor a node.
Google CloudFunctions and Fastly CDN/DDoS:
Why not use Signal for mobile chat?
A look at how private messengers handle key changes
Signal vs. Telegram: Which encrypted messaging app wins?
https://skred.mobi/en/accueil/
It is a branded licensee of TwinMe messenger:
It is Tox-like in that they have video and voice calling as well as text messaging, but claim to be peer-to-peer.
Both were also completely closed-source last time I checked.
Essentially spyware
Like all social media apps, nothing on it is "real", and it's damaging your mental health
It was created to provide safer sexting for young adults and promotes predatory behavior
Like most social media, it tricks you into wanting more and it is addictive
Only snaps are E2E encrypted, not messages or group chats
And it doesn't care about your privacy (see also ToSDR: https://tosdr.org/en/service/311 )
Security Analysis of Telegram (Symmetric Part)
Telegram Messenger Review - January 19, 2021 By Heinrich Long
A look at how private messengers handle key changes
Signal vs. Telegram: Which encrypted messaging app wins?
THE MOST BACKDOOR-LOOKING BUG I'VE EVER SEEN: discovered and fixed in Telegram's self-rolled cryptographic protocol about seven years ago
Telegram reportedly surrendered user data to authorities despite insisting '0 bytes' had ever been shared
Government pressure may have finally won out
MTProto server reimplementation
https://news.ycombinator.com/item?id=25882319
https://www.reddit.com/r/privacytoolsIO/comments/owj0ju/what_do_you_think_of_swisscowss_teleguard/
https://www.washingtonpost.com/technology/2024/02/29/push-notification-surveillance-fbi/
foreign law enforcement officer got TeleGuard to hand over a small string of code that the investigator “provided” the token “as received from TeleGuard, ” without explaining
Threema: Three Strikes, You're Out - Threema boldly claims to be more secure than Signal. Does this hold up to scrutiny?
A Brief Review of the qTox Peer-to-Peer Chat Program
Tox Handshake Vulnerable to KCI (key-compromise impersonation)
FBI Document Says the Feds Can Get Your WhatsApp Data - in Real Time
A previously unreported FBI document obtained by Rolling Stone reveals that "private" messaging apps WhatsApp and iMessage are deeply vulnerable to law-enforcement searches
Yes, You Can Stop Using WhatsApp - But Don't Make This Mistake
A look at how private messengers handle key changes
https://aws.amazon.com/blogs/security/aws-welcomes-wickr-to-the-team/
AWS welcomes Wickr to the team | Amazon Web Services
A look at how private messengers handle key changes
XMPP: Admin-in-the-middle: Server-side parties can transparently modify, log, and monitor nearly everything when communicating via XMPP
XMPP with OMEMO is similar to Matrix MEGOLM for E2EE
What are XMPP and Matrix and what makes them special?
XMPP vs. Matrix
Reasoning Why Disroot went back to XMPP in 2018:
Matrix Closure