blog.bouah.net/content/posts/what-about-design.md

---
title: "What about design?"
date: 2020-07-14T01:32:25+02:00
tags: [XMPP, Design]
---

Who around here hasn't heard about the tragic and inevitable death of XMPP
(eXtensible Messaging and Presence Protocol)? It's a pretty common topic in
the community and around, often started by users of XMPP themselves missing a
certain feature in one or multiple specific implementations, or users of
alternative solutions. In a way this is my own version of why XMPP is or isn't
doomed.

To go down this rabbit hole, we first need to set a few definitions. Most of
my readers would probably know what XMPP is, but I feel obligated to provide a
short reminder as it will allow me to highlight specific points I want to talk
about.

# XMPP? Was ist Das?

XMPP is a communication protocol, that is “nerd” speak to say it's a language
for applications to use and talk together at a level that the end-user doesn't
see. An example would be a chat application: your desktop or smartphone app
talking to a server that then talks to another app.

It is defined as a standard at the [IETF (Internet Engineering Task
Force)](https://ietf.org) -- a standard being the specification of a protocol
(a document, in this case publicised and accessible by anyone), which allows
multiple products implementing what it describes to be able to work together
in an interoperable way.

Core specifications of XMPP are written so that it is easily extendible
allowing any developer to use custom (XML) elements for their own use, and
optionally write a specification for their new feature for everyone else to
use.

XMPP also defines a client-server-server-client model, where a client can talk
with a server that can then talk with multiple servers before reaching other
clients, thus allowing for [decentralization] -- anyone setting up their own
server to be free from restrictions of other operators, and communicating with
the world or part of it.

[decentralization]: https://en.wikipedia.org/wiki/Decentralization#Technological_decentralization

So there we have it: (IETF) __Standard__, __Decentralized__, and
__Extensible__. These are, I believe, the 3 selling-points of XMPP.

From there tons of features can be implemented and then negotiated (as part of
the extensibility) and many things can change to use newer extensions that
weren't considered in the core specifications. For example even the
serialization format (words of the language applications talk, originally XML)
can be changed (just as [EXI][XEP-0322] is doing), and it's also perfectly
fine to have non-compliant behaviour as long as it has been negotiated by
entities taking part in it. And so on…

[XEP-0322]: https://xmpp.org/extensions/xep-0322.html

The [XSF] (XMPP Standards Foundation, previously known as Jabber Software
Foundation) is the entity that did the original work on the protocol and
submitted it to the IETF. It now has a sheperding role. There is no
requirement that XMPP extensions be brought to the XSF, but it aims to be the
place where technical knowledge around XMPP is gathered, so people can get
better feedback when submitting their new specification. Developers have
already layed out lots of protocol bricks for others to reuse through the XSF.

[XSF]: https://xmpp.org
[XEP-0001]: https://xmpp.org/extensions/xep-0001.html
[XSF_mission]: https://xmpp.org/about/xsf/mission.html

# How do applications speak the same language in an extensible world?

This is indeed the core of the problem. While extensibility is one of the
strenghs of XMPP, it's also its main weakness, one of the main points of its
critics. That said, I believe it's not as bad as they make it look like.

It is true that most applications are incompatible one way or another, with
various degrees of significance, either because they don't implement the same
set of extensions, or because an author interprets extensions differently,
or simply because of bugs.

For the rest of this article I will leave aside interpretation issues and bugs
as I consider both of them bugs -- of specifications and/or implementations --
and bugs happen everywhere and can be fixed. Generally, determining what is a
bug and what is a (unintended?) feature is where the issue lies.

While there have been attempts within the XSF at defining common sets of
extensions in what is called “Compliance Suites” (currently updated on a
yearly-basis: [2020][CS-2020], [2019][CS-2019], etc.), they have in my opinion
had mild success for the effort it takes the author to gather feedback and
come up with not-so-controversial changes for newer revisions.

What these Compliance Suites don't take into account so well, despite recent
efforts; and what critics don't account for either when saying XMPP is
missing X, or that all implementations should do Y, is that it's not just
about features and protocols.

The process of coming up with a common set of extensions for an implementation
requires a lot more groundwork. This includes figuring out who the userbase
is, and how the experience for it should be, i.e., design. This process should
be applied across a set of implementations, using the same design guidelines and
ensuring interoperability.

It is not enough if somebody using [Conversations] on mobile talks to somebody
else using [Dino] on desktop, even if they both follow the Compliance Suites
for a given year and can then interop on a “basic” level (which to be honest,
is still pretty advanced), they have different design guidelines and there
will inevitably be areas where they differ and some features won't behave as
expected on the other side. The issue is not that there is no design
guidelines, it's that they're not the same.


[CS-2019]: https://xmpp.org/extensions/xep-0412.html
[CS-2020]: https://xmpp.org/extensions/xep-0423.html


# And in practice?

Multiple solutions following this design process already exist, such as
[Xabber] and [Tigase]. [Snikket] is a new addition in this domain. You can
read about its goals [in the introduction article][snikket-intro] or in a
[more detailed explanation][snikket-explanation] from its author. At the time
of writing it is composed of a rebranded [Prosody] (server) and Conversations
(client), is entirely based on XMPP and federates with the XMPP network. But
the important part -- and also why it deserves a name other than “XMPP” -- is
its goal: to provide a server and a (set of) client(s) that interoperate
properly and have common design guidelines that match the expected userbase.

Maybe you're not part of Snikket's target, in which case there might someday
be a similar solution that's more adapted to your use-case. For the more
technical of us who understand the protocol and/or can deal with less unified
designs, it may be ok to continue using our current applications and work
around these issues ourselves. For the mass audiences I believe this is not an
option.

[Conversations]: https://conversations.im
[Dino]: https://dino.im
[Prosody]: https://prosody.im
[Tigase]: https://tigase.net/tigase-instant-communication
[Xabber]: https://www.xabber.com/
[Snikket]: https://snikket.org
[snikket-intro]: https://blog.prosody.im/introducing-snikket/
[snikket-explanation]: https://www.reddit.com/r/xmpp/comments/f0el07/can_someone_explain_to_me_whats_the_point_of/fgto5h0/

# So why (not) XMPP?

To the question I set to answer at the beginning I say this: Why does it
matter? For whom? My goal is to bring standardization, decentralization, and
extensibility to mass audiences. Not to bring XMPP to them. As explained above
I believe we need product suites with common design guidelines, and they
should include these properties. XMPP has good building blocks but lacks
consorted design.

I want decentralization and standardization to prevent users from being locked
in closed -- often also proprietary -- silos such as WhatsApp, Hangouts,
Slack, MS Teams, Tik-Tok, or even Signal. And I want extensibility to prevent being
stuck in the past and to adapt to the people's needs.


_Comments available on your usual centralized platforms: [reddit] and [HN],
but also [mastodon]._

[reddit]: https://www.reddit.com/r/xmpp/comments/hun47q/what_about_design/
[HN]: https://news.ycombinator.com/item?id=23898679
[mastodon]: https://post.lurk.org/@pep/104546844162627507