How is Wire developed and funded? This was my biggest problem with Matrix (unsustainable funding model for the protocol and no proper standards body).

Why not just use XMPP? Yes, everyone hates XML, but the protocol is well designed, has sustainable funding (via the IETF and XSF), and there's lots of experience out there, and it's flexible enough to develop services like Slack on top of.

Here's what Moxie Marlinspike has to say about the drawbacks of XMPP.

https://signal.org/blog/the-ecosystem-is-moving/

"XMPP is an example of a federated protocol that advertises itself as a “living standard.” Despite its capacity for protocol “extensions,” however, it’s undeniable that XMPP still largely resembles a synchronous protocol with limited support for rich media, which can’t realistically be deployed on mobile devices. If XMPP is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world?

Like any federated protocol, extensions don’t mean much unless everyone applies them, and that’s an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren’t consistently applied anywhere. The implications of that are severe, because someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them. It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience."

I don't think Moxie's right though; you can still do your own thing, and have it work best with your clients which support all the features, and then allow it to federate or optionally allow third party clients on your server with limited functionality. Naturally, you can also contribute back new extensions that you develop too so that other clients and services can adopt them if you want.

But I do tend to agree in general that we need fewer features and less complexity and to push more for basic profiles that everything should implement and that have a clear compliance label.

He wrote that after most messaging had already moved to proprietary networks. That happened primarily because Facebook and Google wanted to lock in users. The most popular desktop clients were multi-protocol clients that were slowly neglected. The most popular mobile clients were hobby projects.

Now we have uncertainty around which networks people use, which devices they use them on, and which features each network supports.

Because XMPP itself is not enough. If you want to deploy XMPP-based chat service in your org, and you want everyone to have same features (offline, mobile, images), you will have a hard time.

You cannot just tell people "go choose any XMPP client, and it will work fine". Instead, it is more like "get XMPP client, but make sure it supports XEP-1111, XEP-2222 and XEP-3333". And if you have multiple platforms (Android, iOS, Win, Linux), let's hope you can find a client for each.

I agree to a certain extent, but I don't think you need to support everything, just the subset of features that a particular user cares about. We should have some form of baseline that's more than the basic protocol, and the Compliance Suites will hopefully help there, but in general as long as basic chat works it should be fine. The first party clients can support everything and give you the best experience, the third party ones are juts in case you can't run the first party clients or need eg. better accessibility support or similar.

For example, I used to use Mcabber with HipChat at work. Mcabber doesn't support even basic modern XMPP things (history, for example), but it was plenty good enough for me to chat with my coworkers.

Its not user thing, it's a community thing. For example, if I have users who cannot see images, it means I cannot post screenshots and expect to get meaningful advice on it.

For your work: Are you connecting Mcabber to HipChat server? Do you use native HipChat client as well?

They are VC funded and sell services (Wire Pro, Wire Red) to large companies.

That seems like enough of a reason not to pick it as a good shared base protocol, even if technically it's good. It's nice that they're funding MLS though; looking forward to the results of that effort.

Could you give some examples of acceptable funding models?

> It is not a goal of this group to enable interoperability/federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security, e.g., standard message transport and application semantics. The focus of this work is to develop a messaging security layer that different applications can adapt to their own needs.

From your link.

All the usual suspects. It'll die like the google chat thing(s).

Always possible. As a counter-precedent of success, https://www.opus-codec.org for WebRTC came from the IETF, Skype and others.

I'm curious, have you followed those discussions, and have you noticed say Google or Facebook do anything to "nudge" the protocol towards being "more convenient to use" (read: less secure) and less privacy friendly than it was originally intended to be?

We're all individuals at the IETF. I have seen people agree to changes that make their job harder because it was the right thing to do.