draft: What about design?

Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>

content/posts/what-about-design.md

@@ -0,0 +1,153 @@
+---
+title: "What about design?"
+date: 2020-07-14T01:32:25+02:00
+draft: true
+tags: [XMPP, Design]
+---
+
+<p style="font-size: 0.9em"><em>Explicit disclaimer: This piece of opinion --
+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 that XMPP
+is doomed with? It's a pretty common topic in channels satellite to the <abbr
+title="XMPP Standards Foundation">XSF</abbr> and XMPP community, often started
+by alternative solutions or users missing this or that feature in one or
+multiple specific implementations. 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 have a
+short reminder as it will allow me to emphasize specific points I want to talk
+about.
+
+# XMPP? Was ist Das?
+
+<abbr title="eXtensible Messaging Presence Protocol">XMPP</abbr> 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 [<abbr title="Internet Engineering Task
+Force">IETF</abbr>](https://ietf.org) that also serves as a home for many
+other building blocks of the Internet and technology all of us use today. The
+IETF itself is guided by their [mission statement][IETF_mission].
+
+[IETF_mission]: https://www.rfc-editor.org/rfc/rfc3935.html
+
+Core extensions of XMPP are written so that it is easily extensible allowing
+anybody 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 negociated (as part
+of the extensibility) and many things can change to use newer extensions that
+weren't considered in the core specifications. For example the serialization
+format (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 negociated by entities taking part in it. And so on…
+
+[XEP-0322]: https://xmpp.org/extensions/xep-0322.html
+
+The <abbr title="XMPP Standards Foundation">XSF</abbr> (previously known as
+<abbr title="Jabber Standards Foundation">JSF</abbr>) is an entity that
+shepards the XMPP protocol. 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 heart of the problem. While extensibility is one of the
+strenghs of XMPP, it's also its main weakness, and one of the main points of
+its critics. I believe it's not as bad as they make it look like though.
+
+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 a mild success for the effort that 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 take into account 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 the mobile
+talks to somebody else using [Dino] on the 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 it's not the same.
+
+
+[CS-2019]: https://xmpp.org/extensions/xep-0412.html
+[CS-2020]: https://xmpp.org/extensions/xep-0423.html
+
+
+# What now?
+
+Recently a solution following this design process called [Snikket] has
+emerged. You can read about its goals [in the introduction
+article][snikket-intro] or in a [more detailed
+explanation][snikket-explanation] from the author. At the time of writing it
+is composed of a rebranded [Prosody] and Conversations, is entirely based on
+XMPP and it federates with the XMPP network, but the important part is that
+the goal is to provide a set of server and client(s) that works together with
+a common set of guildelines.
+
+Maybe you're not part of the target, in which case there might someday be a
+similar solution that's more adapted to your use-case.
+
+For the most technical of us who understand the protocol and/or can deal with
+common design issues, it may be ok to continue using our current clients
+designed for other usages and workaround these issues. For the masses I believe
+this is not an option. Your may take this with a grain 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 that have for only purpose to lock us in
+and make profit off us, again.
+
+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