[Standards] A Meta-Discussion about the Standards Process

Dave Cridland dave at cridland.net
Fri Jan 17 21:53:31 UTC 2020

On Fri, 17 Jan 2020 at 19:28, Marvin W <xmpp at larma.de> wrote:

> On 1/17/20 11:38 AM, Dave Cridland wrote:
> > Well, yes, but the majority of our end-users are probably Fortnite
> > players, and they're not talking to us.
> I should have been more precise: I was talking about the open XMPP
> ecosystem, not any closed/walled garden XMPP implementations with own
> client/server and without federation. Those don't care too much about
> the standard anyway (they can just do proprietary vendor extensions and
> probably do).
That depends. In my experience, a lot of the draw for XMPP is the fact it's
an off-the-shelf solution with interoperable pieces. That's (at least) a
by-product of standardization.

So, for example, Pando (my employer) uses a lot of standards-based things,
and things which aren't standards but are still off the shelf (like ESL's
MUC Light and Inbox). There is some proprietary stuff, but there's also a
lot of "throw this thing in a message", which is not so useful (hence UDT).
Everything we do, though, is moving toward the standards - where we haven'
is mostly expediency. And Pando is (currently) a custom client talking to a
single XMPP service; in the terms you've described, it's a closed walled
garden. (I'll talk about, and show, our app at the Summit for those
interested; it's used across the National Health Service in the UK by
Doctors, Nurses etc as a primary communications tool).

But there are also lots of closed networks where the ability to use an
off-the-shelf client and server is very useful, and plenty more where at
least using a fully standardized server is useful. Fortnite is the latter,
and while I'm struggling to think of a good example of the former, they do

And then there's the militaries, where despite a closed network, there's a
lot of federation, and standards are fully mandated. Some players in that
market handle this by simply adopting standards, others handle that
constraint by very active involvement in the XSF and produce a number of
XEPs - and many of those are of use for a wider audience.

> The reason why WHATWG worked is that their specs were implemented by the
> majority of browsers (counted in users) and thus websites can and will
> rely on these specs. As soon as they do, any other browser will need to
> implement the same spec to stay compatible or loose even further market
> share. "Fortnite" wouldn't matter because they have a browser that can
> only display a single website and that website is only ever displayed in
> their browser.
Yes; the effect has also been to gradually reduce diversity in
the browsers, and lock out new entrants. But I think we're already agreed
that WHATWG, for all its successes, has had some serious downsides.

In the chatroom, after Guus commented on the one-liner you've replied to, I

‎[10:48:05] ‎dwd‎: I probably should have expanded on that. But
"consumer-grade" instant messaging is pretty small beans for XMPP. Embedded
use of XMPP into games is, I think, the largest use by numbers of users,
and I'm not sure what would be next - probably military, though possibly
financial trading.
‎[10:49:28] ‎dwd‎: That doesn't mean I don't think consumer-grade messaging
isn't important, or that we should ignore enterprise messaging (ie, Slack)
because we're barely present. Strategically, both those make more sense to
concentrate on than gaming (and won't harm gaming either), at least in
terms of features.

I'll expand on this yet further:

The specifications we produce have to have relevance and adoption, that's
certainly true, and the consumer-grade messaging that the majority of the
Open Source folks are dealing with day-to-day is a very useful guide to
this. The military, being people, too, will end up using emoji-based
reactions - in fact, they'll probably mandate their use eventually. So
while the "personal IM" market is small for XMPP, it's probably leading in
terms of UX, it's highly accessible for us, and it's a good guide to what's
needed for current trends in messaging.

Similarly, though we have even less footprint in the enterprise case,
ignoring that would be extremely foolish for us - especially when the
incumbents have some increasingly difficult to solve UX issues, and are
edging toward some form of pseudo-federation that we can already give. We
should, from a strategic point of view, be focusing on the well-defined
needs of these two markets.

What I wouldn't want to do is focus on these or any particular markets
exclusively to the detriment of some of our other, often more outré and
esoteric, markets, which don't seem as exciting (or as pure, or whatever).
I appreciate that many have mixed feelings about the military use, for
example, but I would hope even committed pacifists in the community can at
least take some pride that XMPP dominates the military because of its
technical qualities (and the fact it's a recognised Open Standard). The
benefit to the community is that we have a more broadly applicable set of
specifications, with solid capability for (for example) low bandwidth and
so on.

And, you know, being able to say "Military Grade Security" to the
enterprise market and actually *mean* it wouldn't be all bad.

Losing Fortnite wouldn't, I admit, make a huge difference to most of the
community, though by the sounds of things, Guus would lose the respect of
his kid - and I can tell you that it gets a lot of interest when you're
trying to explain why XMPP is interesting to the crowd at FOSDEM.

OMEMO is kind of an example where we got in a similar situation: so many
> clients (counted in user numbers) in the open XMPP ecosystem do support
> it, that to stay compatible with the ecosystem, you kind of have to
> implement it. That's mostly not relevant for walled gardens though.

I'm not sure that's true either - E2EE is really important to many places,
even walled gardens, and because the attraction of XMPP is a proven
technology that people can pick up and use, the fact that they cannot with
OMEMO is a serious problem. (Worse, OMEMO has been in use by people
presumably unaware that their software is inadvertently GPL).

So I think it certainly should be relevant for walled gardens, and almost
certainly is already.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200117/cada014c/attachment.html>

More information about the Standards mailing list