2 ms·

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

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.

walterbell 8y ago
They are VC funded and sell services (Wire Pro, Wire Red) to large companies.
- SamWhited 8y ago
  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.
  - walterbell 8y ago
    Could you give some examples of acceptable funding models?
blancNoir 8y ago
Here's what Moxie Marlinspike has to say about the drawbacks of XMPP. https://signal.org/blog/the-ecosystem-is-moving/ 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."
- SamWhited 8y ago
  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.
- pseudalopex 8y ago
  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.
theamk 8y ago
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.
- SamWhited 8y ago
  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.
  - theamk 8y ago
    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?

walterbell 8y ago

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

SamWhited 8y ago
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.
- walterbell 8y ago
  Could you give some examples of acceptable funding models?

blancNoir 8y ago

Here's what Moxie Marlinspike has to say about the drawbacks of XMPP. https://signal.org/blog/the-ecosystem-is-moving/ 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."

SamWhited 8y ago
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.
pseudalopex 8y ago
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.

theamk 8y ago

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.

SamWhited 8y ago
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.
- theamk 8y ago
  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?