164 lines
8.1 KiB
Markdown
164 lines
8.1 KiB
Markdown
---
|
|
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
|