163 lines
8 KiB
Markdown
163 lines
8 KiB
Markdown
---
|
|
title: "What about design?"
|
|
date: 2020-07-14T01:32:25+02:00
|
|
draft: true
|
|
summary: |
|
|
Who around here hasn't heard about the tragic and inevitable death of XMPP?
|
|
It's a pretty common topic in the community and around, often started by
|
|
users of XMPP themselves missing this or that feature in one or multiple
|
|
specific implementations, or users of alternative solutions. In a way this
|
|
is my own version of why XMPP is doomed (or isn't). What could be a cause
|
|
for most of these accusations?
|
|
tags: [XMPP, Design]
|
|
---
|
|
|
|
<p style="font-size: 0.9em"><em>Explicit disclaimer: This viewpoint -- as any
|
|
other article on this blog -- is a work in progress, and I'm happy to debate
|
|
it and listen to constructive feedback.</em></p>
|
|
|
|
|
|
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
|
|
this or that feature in one or multiple specific implementations, or users of
|
|
alternative solutions. In a way this is my own version of why XMPP is doomed
|
|
(or isn't). What could be a cause for most of these accusations?
|
|
|
|
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 emphasize 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 public and accessible by anyone), that 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 server/client model, where multiple servers can
|
|
communicate together, thus allowing for [decentralization] -- anyone setting
|
|
up their own server to be free from restrictions of other servers, 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 Standards
|
|
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 could get
|
|
better feedback when submitting their new specification.
|
|
|
|
[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, either because an author interprets extensions differently,
|
|
or because of plain bugs.
|
|
|
|
For the rest of this article I will leave aside the last two points --
|
|
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 has 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-controvertial 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.
|
|
|
|
In practice 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 of year X and can then interop on a “basic” level (still
|
|
pretty advanced to be honest), 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
|
|
|
|
|
|
# What now?
|
|
|
|
A solution called [Snikket] following this design process has recently
|
|
emerged. 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 different name -- is its goal: 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. You may take this with a pinch of salt as it is as a
|
|
developer that I am saying this to you.
|
|
|
|
In the end why does it matter to the end-user if it's actually XMPP that's
|
|
being used, as long as these new solutions incorporate properties we care
|
|
about such as standardization, decentralization, and extensibility? so that we
|
|
don't end up again with closed silos (Slack, WhatsApp, Signal?, etc.) that
|
|
have for sole purpose to lock us in.
|
|
|
|
I guess the only thing left to figure out now is [network
|
|
effect][network-effect]…
|
|
|
|
[Conversations]: https://conversations.im
|
|
[Dino]: https://dino.im
|
|
[Prosody]: https://prosody.im
|
|
[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/
|
|
[network-effect]: https://en.wikipedia.org/wiki/Network_effect
|