Riot, and Matrix in general, were designed to beat that: It's designed to inter-operate with existing chat protocols as much as possible, so that this isn't a problem, but also to provide things that those protocols can't.
Absolutely; as much as the Matrix people claim they're not doing that by "interoperating with other protocols" they don't seem to understand that it's exactly what they're doing. The existing standards (XMPP) already interop in exactly the same way (gateways/transports), so making another protocol instead of improving the gateway / transport story on an existing one is just silly.
Matrix is group-chat-first ("direct messages", or one-to-one messages, are actually just implemented as an unnamed group with two people in it), while XMPP's group chat support is in a rather unwieldy extension (as with a lot of XMPP's functionality).
Matrix also builds on existing standards with decent libraries available for things like voice/video chat, and is web- and mobile-first. There's integration of arbitrary client-defined "push services" built into the protocol, which Riot uses to push events from a Matrix server through Google and Apple's cloud device messaging services to save battery, all without the Matrix server having to know the details of how those push systems work. Also, I can do web-based single sign-on through my CAS server, and all the variations of Riot handle it perfectly.
Mmm... I wouldn't quite call it silly. The protocol does support better stuff than XMPP. We're talking about single view notifications across multiple clients and other goodies sometimes implemented by XMPP plugins. And quite frankly from what I've heard the plugins are a pain. I do think a fresh break is what's needed.
I don't disagree that XMPP has problems, like anything, but having multiple federated protocols defeats part of the purpose of federation. Also, as far as I can tell, Matrix just carried over most of the same problems because they don't have 20 years of fixing edge cases and making sure things are scalable and easy. I'm not sure why plugins would be a pain; I'm sure making recommendations could be done better, but otherwise they're no more difficult to implement than the same things in the Matrix core spec. A fresh break is most cretainly not what's needed; we just need people to volunteer their time and effort and help make things better, not make up new protocols to compete with the old ones and make the messaging ecosystem more fragmented than it already is.
I get the 'different philosophy' part, but I don't understand why their list of 'problems with XMPP' includes things like 'second-class citizen', since Matrix itself is a second-class citizen compared to XMPP.
They might as well list 'Can't talk via Skype' as a problem with XMPP, since it's just as true and Matrix is just as incapable of solving it.
As for 'requires plugins/extensions', if you think that's a problem then there's an easy fix: define a new protocol as "XMPP + the following extensions...". That requires some effort, e.g. to get servers and clients to support this new protocol, but unlike a "clean break" it wouldn't require much technical or social work.
I especially enjoyed the "no open source implementation exists" reasoning; no open source implementation of Matrix used to exist, but that didn't stop the developers ;)
As parent said, XMPP covers all of these cases with plugins. The FAQ you link says, over and over again, "the base setup doesn't cover these features, but plugins do," and doesn't explain away writing improved plugins or XMPP spec extensions. All I see is "buttt it'ss haaaaarrdddd".
> Rather than fighting over which open interoperable communication standard works the best, we should just collaborate and bridge everything together.
The XEP which allows all clients that a user has open to actually receive messages has not even been accepted yet. Last Call was supposed to finish on 2015-08-28 - 11 years after the advent of XMPP - and the document hasn't been updated since. Many clients don't support it, including Pidgin, and at least the Prosody.IM server needs a "community module" to enable support for it.
XMPP is a pretty terrible user experience, tbh, and its developer experience isn't a whole lot better.
Matrix actually has a good point about the spec extensions though: if your spec is that minimal, nobody is going to be able to agree on what feature set to support. As a Schemer, I can attest to that.
>Absolutely dripping with irony.
As is your comment. Matrix made a different set of design tradeoffs, and is a legitimate protocol in its own right. And yet every time it pops up on HN, people complain about how we should all just use XMPP.
Screw that. XMPP isn't perfect, and there is room for a chat protocol that solves these problems in a different way.
> Matrix actually has a good point about the spec extensions though: if your spec is that minimal, nobody is going to be able to agree on what feature set to support.
If that were true, nobody would agree on which Matrix features to support either. What difference would it make if Matrix just-so-happened to be defined as "XMPP, plus the following extensions..."?
> As a Schemer, I can attest to that.
It's one thing to say "the Scheme spec is too minimal; I'm going to make Racket a hard dependency", it's quite another to say "the Scheme spec is too minimal; I'm going to invent my own Python derivative"
Actually, that's pretty much what Racket did: Racket isn't a superset of Scheme, any more than Clojure is a superset of Common Lisp.
>If that were true, nobody would agree on which Matrix features to support either. What difference would it make if Matrix just-so-happened to be defined as "XMPP, plus the following extensions..."?
because some of Matrix's design decisions are fundamentally different from those of XMPP. also, the reason why everybody agrees about Matrix features is that they have no choice: there's a far larger base standard than there is for XMPP.
Leveraging http for file transfer - via, say, web apps - avoids "civilian" (non-techie) users from having to install yet another tool (like ftp client)...though I do agree that browsers shouldn't replace every other tool under the sun. ;-)
As someone who appreciates the design goals of both but is a user of neither Matrix nor XMPP for practical reasons (I don't know anyone who is), seeing users of both of these small networks sighing at each other leaves me nonplussed.
An end-to-end solution for interop between the two ought to be insanely high on the priority list. By this I mean it should be braindead obvious if I want to try one of them how to chat with a user of the other. Obviously this is bigger than just the protocol but so what, it's the problem that needs to be solved.
I can't even imagine how working together would not be top of everyone's mind in this space, since chat is all about network effects. The incentives to cooperate are huge.
Yes, of course Mark Shuttleworth's personal blog is not bias (he's the owner of Canonical).
Also, he's talking about deployments on Digital Ocean, ie. VM's. I'm talking about what actually makes the "cloud", ie. the "cloud". The "cloud" is built out of RHEL/Centos for the most part. Almost all the major "cloud" infrastructures have been built with RHEL/Centos. We can speculate why... but Red Hat has built a $1 billion+ revenue per year company out of "cloud" and enterprise support contracts. (because they were there first, and they focused on it... and after it became profitable, then they finally branches out into other markets.)
The problem with Canonical IMO is they try to get into too many markets which ends up resulting in split finite resources. "Jack of all trades, master of none".
Free Desktop OS is a loss leader, no way they'll make significant profit out of that. Better to make the best Free Linux desktop OS in the world, get lots of people using it, hopefully among them some engineers, influencers, and decision makers, then provide server/cloud products and services based on that same tech.
For one single data point, that's exactly why I use Ubuntu server for all my cloud deployments - because I use Ubuntu desktop and know the Ubuntu/Debian ecosystem really well.
Nothing wrong with that current business model, any problems are more a matter of execution and competing against - as you point out - heavily entrenched first movers. But focusing on desktop won't save them, especially since desktop is saturated and already peaked. Cloud and mobile is where the growth is now.
I wonder why they chose to use Intel NUC for this. It has dire price/performance. I built a cluster (see http://rwmj.wordpress.com/?s=cluster) recently, and I used AMD hardware for it because (as of right now) the performance is unbeatable for the price. I have a 32 core cluster that cost me £1300 including everything except a metal box to put it in.
That's pretty cool. One of the goals for the orangebox was being robust and compact enough to throw in a suitcase and fly to a conference. The nucs win on compactness, and also via intel's vpro/amt can do remote power management (ie. ipmi light).
Nice -- didn't know that Intel now had a serious remote management offering. These AMD mobos do wake-on-LAN, and that's it. They don't even have serial BIOS.
To be honest, Intel's AMT is a bit of a PITA, but the Orange Boxes were assembled to have some resemblance to real racks of hardware. So remote out of band power control is essential.
There's something quite magical about using Juju and MAAS on the Orange Boxes and seeing the LEDs light up as you scale out a service (e.g. juju add-unit -n 5 nova-compute).
Every single Supermicro and Tyan board I've ever used. Also every Dell, HP, and Sun/Oracle server I've ever used (though those can be a bit more of a pain). Really, anything with a halfway-decent IPMI implementation.
The IPMI spec lets you send the entire console (BIOS through login boot cycle) out either the hardware serial port, or over a LAN for all those platforms.
Portability; from looking at your site you're using a standard ATX motherboard. The Orange Box is for demoing MAAS/OpenStack and needs to be portable enough to go on a plane.
Cool cluster btw, it'd be neat to see you blog about using MAAS on it.
The critical difference is once a new version of iOS is released Apple stop distributing the old one (with a slight exception when the iPad first came out, and was on 3.2).
Only today Samsung have announced some new handsets at MWC that still run Gingerbread...
The problem with these comparisons is that people take the rollout date of the end user operating system iOS and compare it to the first release date of the first OS based on a new version of Android.
Since iOS has no cross platform component similar to Android, it would make more sense to compare it to Google's Nexus OS or to Samsung's Galaxy OS.
I think the term "operating system" is so generic that it confuses a lot of people in these discussions. To many people and most tech journalists, the operating system is all software in a device before you install additional software. And by this definition, Android is not an operating system.
my bad, I checked Wikipedia and got deceived by the phrase “[…] officially launched at the Galaxy Nexus and Ice Cream Sandwich release event on 19 October 2011” but then it says only the SDK was released that day. so, one month difference instead of one week.
