Chat/Instant Messaging protocols comparison

Comparison Table

ProtocolDecentralizedEncryptionMain Use CaseExamples
XMPPYesOptionalFederated messagingejabberd, Prosody
MatrixYesYesDecentralized chatElement, Synapse
SignalNoYesSecure messagingSignal, WhatsApp
SIPNoOptionalMultimedia communicationAsterisk, Linphone
IRCNoNoCommunity channelsLibera Chat, EFnet
ActivityPubYesOptionalSocial networkingMastodon, Pleroma
WebRTCPeer-to-peerOptionalReal-time communicationVideo calls, games
ToxYesYesPeer-to-peer messagingqTox, µTox
Slack RTMNoNoTeam collaborationSlack
MTProtoNoYesSecure messagingTelegram
JingleYesOptionalReal-time multimedia (via XMPP)Conversations, Dino

Matrix protocol servers :

Server NameRepositoryLicenseLanguageDescription/FocusMaturityKey Features
Synapsegithub.com/matrix-org/synapseApache 2.0PythonReference implementation, feature-rich, large-scale deployments.MatureFull spec compliance, federation, E2EE, bridges, application services, admin APIs, horizontal scaling.
Dendritegithub.com/matrix-org/dendriteApache 2.0Go“Second-generation” homeserver, performance-focused, smaller footprint.DevelopingGood performance, smaller footprint, aims for full spec compliance, monolithic/polylith deployments, sliding sync.
Conduitgitlab.com/famedly/conduitAGPLv3RustCommunity-driven, speed, simplicity, ease of self-hosting, lightweight.DevelopingFast, lightweight, simple deployment, SQLite/PostgreSQL/MySQL support, good for small/medium deployments.
Constructgithub.com/matrix-construct/constructISCC++High-performance server for large, complex deployments.ExperimentalHighly performant, aims for very large deployments, customizability.
Ruma(No single repo – see description)MITRustCollection of Rust libraries for building Matrix clients/servers/services.VariesBuilding blocks for custom Matrix software in Rust, high customization.

Matrix protocol compatible clients :

Client NamePlatformsLicenseLanguage(s)Description/FocusSpec ComplianceUI TechnologyKey Features
ElementWeb, Desktop (Linux, macOS, Windows), Mobile (iOS, Android)Apache 2.0JavaScript (React), TypeScript, Swift, KotlinFlagship client, feature-rich, modern UI.HighWeb (React), variousE2EE, Spaces, Threads, Voice/Video, Widgets, Rich Text, Polls, Location Sharing, Communities, Cross-signing, Key verification.
SchildiChatWeb, Desktop (Linux, macOS, Windows), Mobile (Android)AGPLv3JavaScript (React), TypeScriptFork of Element, improved UX.HighWeb (React)All Element features + UI/UX improvements (themes, faster startup, better notifications, media handling).
FluffyChatMobile (iOS, Android), Web, Desktop (Linux, macOS, Windows)AGPLv3Dart (Flutter)User-friendly, ease of use, clean interface, multi-account.MediumFlutterE2EE, Simple UI, fast, cross-platform, push notifications, multi-account.
NhekoDesktop (Linux, macOS, Windows)GPLv3C++ (Qt)Native desktop client, speed, efficiency, keyboard-centric.MediumQtE2EE, fast, native look, keyboard shortcuts, reactions, redactions, room upgrades, basic Spaces support.
NeoChatDesktop (Linux, macOS, Windows), Mobile (Android)GPLv3C++ (Qt, Kirigami)KDE-based client, KDE Plasma integration.MediumQt, KirigamiE2EE, KDE integration, clean interface, follows KDE Human Interface Guidelines.
HydrogenWebApache 2.0JavaScript (vanilla)Lightweight web client, speed, minimal resource usage. Runs well on low-powered devices.MediumCustom (vanilla JS)Fast, lightweight, low-end hardware support, E2EE, basic features.
weechat-matrixTerminal (Linux, macOS, Windows via WSL)GPLv3C, Python, Lua, etc.Plugin for WeeChat IRC client, terminal Matrix support.MediumTerminal (ncurses)Terminal-based, customizable, integrates with WeeChat’s features (scripting, triggers).
gomuksTerminal (Linux, macOS, Windows via WSL)AGPLv3GoTerminal-based client in Go, inspired by weechat-matrix.HighTerminal (tview)E2EE, fast, relatively feature-rich for a terminal client (image previews, reactions).
matrix-commanderTerminal (Linux, macOS, Windows via WSL)MITPythoncommand-line tool

Social media protocols comparison

Comparison of ActivityPub, AT Protocol, and Matrix Protocol (mainly a reminder for myself) “

FeatureActivityPubAT ProtocolMatrix Protocol
Primary Use CaseSocial networking (microblogging, content sharing)Social networking with algorithmic controlReal-time communication (chat, VoIP)
Commands/VerbsCreate, Update, Delete, Follow, Like, Announce (Repost)Create, Update, Delete, Follow, Like, Repost, Algorithmic ChoiceSend, Receive, Join Room, Invite, Leave
Data ModelActivity-Object Model in JSON-LDJSON with user-defined schemasJSON (events model for real-time updates)
Transport ProtocolHTTPS, with JSON-LDHTTPS, with JSONHTTP (REST) and WebSocket, with support for end-to-end encryption (E2EE)
Identity ManagementTied to server domain (e.g., @user@domain.com), uses WebFinger for discoveryPortable DIDs for decentralized identityTied to server domain but portable; user ID format is @user:domain.com
FederationFederated, allowing instances to share content and social connections across domainsFederated with content and algorithm controlFederated, with real-time, synchronized state across servers
InteroperabilityWidely interoperable with other ActivityPub-compliant platforms in the FediverseDesigned for custom app experiences, interoperability is in developmentSupports interoperability with other Matrix clients; bridges to other protocols (e.g., Slack, IRC)
End-to-End EncryptionNot native to protocol but possible with extensionsNot natively specifiedBuilt-in and widely supported, particularly in 1:1 and group chats
ModerationInstance-based moderation policies, customizable filters and blocksUser-level and instance-level moderation, customizable algorithmsRoom-level moderation, with granular permissions for room admins
Popular PlatformsMastodon, PeerTube, Pixelfed, WriteFreelyBluesky Social, upcoming decentralized appsElement (main Matrix client), Synapse (server), bridges for Slack, Discord, Telegram, etc.

Summary of Key Differences

  • ActivityPub is best suited for federated social networking, particularly for applications that prioritize openness and content sharing across platforms in the Fediverse. It uses an Activity-Object model with JSON-LD and supports instance-based identity.
  • AT Protocol focuses on user control over content algorithms and portable identities using DIDs, with a vision for interoperability in custom social applications. It is also designed for federated social networks but with more control over data portability and algorithmic transparency.
  • Matrix Protocol excels in real-time, federated communication, supporting secure, encrypted messaging with granular moderation capabilities. It’s heavily used for chat, VoIP, and collaborative tools, emphasizing interoperability with other platforms through bridges.

Code-First Approach vs. Design-First Approach

Some people aren’t able to think/design a software algorithm without writing the code that implements it; some other can just think/rethink at an algorithm without even writing a single line of code until it is almost totally clear in their mind, and then they code it. These are two extremes of the different approaches to designing/implementing and algorithm. Of course mixed approaches are what happen normally but let’s try to identify the extreme sides in terms of how they work.

Code-First Approach (Bottom-up or Implementation-Driven Approach):

  • This approach involves thinking through the problem by immediately writing code.
  • Developers using this method tend to experiment with implementations as they go.
  • It’s often associated with a more hands-on, trial-and-error style of problem-solving.
  • This approach can be beneficial for smaller problems or when working with familiar concepts.
  • It might be referred to as “thinking with your fingers” or “coding to think.”

Design-First Approach (Top-down or Conceptual Approach):

  • This approach involves thoroughly thinking through and designing the algorithm before writing any code.
  • Developers using this method often use abstract thinking, mental models, or visual aids like flowcharts or pseudocode.
  • It’s associated with a more theoretical or analytical style of problem-solving.
  • This approach is often beneficial for complex problems or when designing large-scale systems.
  • It might be referred to as “whiteboard coding” (even if no actual whiteboard is used) or “algorithmic thinking.”

Both approaches have their merits and can be effective depending on the situation, the complexity of the problem, and the individual developer’s style. Many experienced developers can switch between these approaches as needed.

It’s worth noting that in practice, many developers use a combination of both approaches, iterating between design and implementation as they work through a problem. This hybrid approach allows for both conceptual planning and practical experimentation.

Some related concepts and methodologies that incorporate aspects of these approaches include:

  1. Test-Driven Development (TDD): Writing tests before implementation, which can be seen as a form of design-first thinking.
  2. Rapid Prototyping: Quickly implementing ideas to test them, which aligns more with the code-first approach.
  3. Model-Driven Development: Focusing on creating and analyzing domain models before implementation, which is more aligned with the design-first approach.

Understanding these different approaches can help developers recognize their own problem-solving styles and potentially expand their toolkit by practicing alternative methods when appropriate.

Big Internet services backend technology map (always out of date )

  • Airbnb: Ruby on Rails, MySQL, Amazon Web Services (AWS)
  • Uber: Go, Node.js, Java, Python, PostgreSQL, MySQL, Redis, Kafka
  • GitHub: Ruby on Rails, Go, Erlang, MySQL, Redis
  • WhatsApp: Erlang, FreeBSD, Yaws, Ejabberd, Mnesia DB
  • LinkedIn: Java, Kafka, Hadoop, Cassandra, Oracle, Voldemort (LinkedIn’s own distributed database)
  • Netflix: Go, Gluster, Apache Tomcat, Hive, Chukwa, Cassandra, Hadoop, MySQL, Amazon Web Services (AWS)
  • Slack: PHP, Java, MySQL, MongoDB, Kafka
  • Facebook: PHP (HHVM), React, GraphQL, MySQL, Cassandra
  • Twitter: Scala, Java, Ruby, MySQL, Aurora, Redis
  • Spotify: Python, Java, ZeroMQ, PostgreSQL, Cassandra, Google Cloud Platform (GCP)
  • Pinterest: Python (Django), Java, Redis, Cassandra, Kafka
  • Snapchat: Python, Java, PHP, Cassandra, Google Cloud Platform (GCP)
  • Dropbox: Python, Go, Rust, MySQL, Amazon Web Services (AWS)
  • Zoom: C++, Java, MySQL, Kafka, Amazon Web Services (AWS)
  • Shopify: Ruby on Rails, MySQL, Redis, Liquid (templating), Google Cloud Platform (GCP)
  • TikTok (ByteDance): Python, C++, Java, Nginx, MySQL, Kafka
  • Reddit: Python (Django), PostgreSQL, Redis, RabbitMQ, Amazon Web Services (AWS)
  • Instagram: Python (Django), React, PostgreSQL, Redis, Amazon Web Services (AWS)

sunovermonte

The charm of complication

(or the Attraction for Complexity) There is a very common tendency in computer science and it is to complicate solutions. This complication is often referred as incidental/accidental complexity i.e. anything we coders/designers do to make more complex a simple matter. Some times this is called over engineering and stems from the best intentions :

  1. Attraction to Complexity: there’s often a misconception that more complex solutions are inherently better or more sophisticated. This can lead to choosing complicated approaches over simpler, more effective ones.
  2. Technological Enthusiasm: developers might be eager to try out new technologies, patterns, or architectures. While innovation is important, using new tech for its own sake can lead to unnecessary complexity.
  3. Anticipating Future Needs: developers may try to build solutions that are overly flexible to accommodate potential future requirements. This often leads to complex designs that are not needed for the current scope of the project.
  4. Lack of Experience or Misjudgment: less experienced developers might not yet have the insight to choose the simplest effective solution, while even seasoned developers can sometimes overestimate what’s necessary for a project.
  5. Avoiding Refactoring: In an attempt to avoid refactoring in the future, developers might add layers of abstraction or additional features they think might be needed later, resulting in over-engineered solutions.
  6. Miscommunication or Lack of Clear Requirements: without clear requirements or effective communication within a team, developers might make assumptions about what’s needed, leading to solutions that are more complex than necessary.
  7. Premature Optimization: trying to optimize every aspect of a solution from the beginning can lead to complexity. The adage “premature optimization is the root of all evil” highlights the pitfalls of optimizing before it’s clear that performance is an issue.
  8. Unclear Problem Definition: not fully understanding the problem that needs to be solved can result in solutions that are more complicated than needed. A clear problem definition is essential for a simple and effective solution.
  9. Personal Preference or Style: sometimes, the preference for certain coding styles, architectures, or patterns can lead to more complex solutions, even if simpler alternatives would suffice.
  10. Fear of Under-Engineering: there can be a fear of delivering a solution that appears under-engineered or too simplistic, leading to adding unnecessary features or layers of abstraction.