[Standards] XMPP team activity

Ralph Meijer ralphm at ik.nu
Tue Sep 29 14:30:03 UTC 2015

On 2015-09-29 12:55, Evgeny Khramtsov wrote:
> Tue, 29 Sep 2015 12:25:28 +0200
> Stefan Strigler <stefan.strigler at gmail.com> wrote:
>> Strange, I'm being paid since years for doing exactly this.
> I'm doing just the same. With a few proprietary extensions this can be
> done just fine. But I think that is not the right direction for XMPP
> developers in general.
>> You're free to contribute!
> But what if I disagree on some positions with XSF? Like jingling or
> pubsubbing everything. Obviously I cannot contribute to the solution I
> don't see useful. I wouldn't complain if they worked fine, but
> they don't.


I've been reading this thread and want to make a few things clear about
XMPP, the XSF, and the community, and how they relate.

First off, I'd like to make it clear that the XSF is (just another)
standards body that tries to find common ground in real-time messaging
applications. It does that by providing a process for enhancement
proposals to be examined on technical merit, basically to define a
collection of generic building blocks to build real-time applications.
This process eventually results in published documents in the form of
XMPP Enhancement Proposals (XEPs) and is guided by the XMPP Council that
is elected from and by the XSF membership.

Additionally, the XSF tries foster the XMPP community by providing
discussion venues (mailing lists, group chat rooms and summits), being a
representative towards other (standards) bodies, and even being a mentor
organization for Google Summer of Code to improve implementations of
real-time applications based on XMPP.

However, we do not control the community. This is important. The
community is bigger than the XSF and due to nature of how XMPP is
distributed in nature, both in architecture and in how you can define
extension protocols, it cannot be the end-all and be-all of everything
XMPP. Also note that the core XMPP protocols are defined in another
standards body: the IETF.

The XSF itself also does not currently provide, endorse, or actively
contribute to XMPP implementations. In fact we have so far actively
tried to not favor particular server, client and library implementations
in our communications.

To get back to your original remarks. Yes, it is ok for applications to
have proprietary extensions. Sure, we'd love to define a generic way for
extensions that are common enough to be of general use. Often, though,
running code beats standards documents. Building first and then coming
to the XSF to define it properly based on experience is a great
approach. Even if it is using a different approach than other
enhancement proposals. If anything, it improves discussion around a
certain problem domain. Disagreement is a great conversation starter.

Additionally, you say that you don't like "jingling or pubsubbing
everything". As it turns out, there are patterns in the different
building blocks we've thought up over the last 17 years. If we were to
redesign the whole thing, stuff might look a lot different. Jingle is
the culmination of work on several different approaches towards
signaling for setting up audio/video connections and file transfer. In
fact, Jingle's development was a great influence to how WebRTC has been
designed and why it is a natural fit for signaling WebRTC applications.
I'd also say that because of WebRTC, it is easier to take those building
blocks and reuse them for non-web implementations, using Jingle.

The observer pattern (also known as publish-subscribe) is hidden within
almost all of our building blocks. In fact, I know of at least one
server implementation that is wholly publish-subscribe based, but
provides access using the standard (non XEP-0060-based) protocols. This
is why you will hear a lot of talk about publish-subscribe for a next
generation multi-user chat protocol. It is just a good fit and solves a
bunch of problems that are currently really hacks in XEP-0045.

But I think most of the "it doesn't work" is not because of protocol,
but actual implementations. Like you, I'd love to see a system like
Whatsapp, Slack, GitHub, etc. using standard XMPP protocols with a great
UI for all major platforms (web, Android, iOS, Windows Phone, Linux
desktop, OS X, and Windows desktop). However, again, this is not the
domain of the XSF. Some one, some group or some company, would need to
invest time and money to make this a reality. I don't believe the
protocols themselves are the issue here. Implementations are.

Also note that XMPP is way more than "just chat". There is a big effort
around non-persons communicating using XMPP, including the so-called
Internet of Things (IoT).

In the end, this is simply a doacracy: those who do the work get stuff
done. Work includes writing code, documentation, UI design, research,
and cooperation with other standards bodies. As you mentioned,
implementations are in different states regarding the implementation of
(sometimes still experimental) extensions. To align them, people will
need to dig in and bring together implementors. The XSF is surely a
great place to facilitate such discussions, but is not in a position to
enforce convergence around certain applications.



More information about the Standards mailing list