<story><title>Mattermost: Open-source, on-premises, Slack alternative</title><url>http://www.mattermost.org/</url></story><parent_chain><item><author>heavenlyhash</author><text>Lots of people -- in that list, even -- started with XMPP based systems.  They all move away.  At first, I also thought this was an open and shut case of interest in lock-in.  Now, I&amp;#x27;m not going to say that isn&amp;#x27;t true, but it&amp;#x27;s also worth considering that XMPP... just isn&amp;#x27;t that good.&lt;p&gt;Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to admit: XMPP is... it&amp;#x27;s decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work.  I can&amp;#x27;t honestly fault anyone who started with XMPP and then rapidly started looking to get off.&lt;p&gt;Examples:&lt;p&gt;- unique message IDs? Absent. XEPs kind of provide; but I can&amp;#x27;t tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...).&lt;p&gt;- multi device? Oh. My. God. It&amp;#x27;s bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages.&lt;p&gt;- there&amp;#x27;s a concept of &amp;quot;message carbons&amp;quot; to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering.&lt;p&gt;Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of &amp;quot;all clients should see the same picture&amp;quot;.&lt;p&gt;Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it&amp;#x27;s all considered &amp;quot;extensions&amp;quot;. Stuff like message IDs fundamentally shouldn&amp;#x27;t be an extension because it&amp;#x27;s just too critical that all minimum-viable clients agree. You just can&amp;#x27;t build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features.&lt;p&gt;I want an open chat protocol.&lt;p&gt;I thought XMPP might be the one. Then I actually looked at it. Tried to write something with it.&lt;p&gt;XMPP is not prepared to be the one, in any sense at all except for legacy support. I have all the respect in the world for all the folks who put effort into trying to make an open chat standard, but... honestly, we need a stronger foundation than this.&lt;p&gt;(N.b. These complaints are a shameless repost from another not-very-old thread about chat where XMPP was also raised: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9718784&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9718784&lt;/a&gt; .)&lt;p&gt;I&amp;#x27;ve since looked at matrix.org ... and I&amp;#x27;m &lt;i&gt;really&lt;/i&gt; impressed.  The standard is completely reasonable.  It&amp;#x27;s the first federated chat standard I&amp;#x27;ve seen proposed that actually has loose timing systems that&amp;#x27;s both available during a partition and can reach consistency afterward (messages list their last-seen messages, and so act like vector clocks, an accepted good solution to problems in CAP territory).  You could actually take two systems with clock skew and have them reach a single, reconciled view of the world, even after netsplits.  And practically speaking... man, go look at their list of clients.  Despite being a relatively young project, matrix has clients on every major platform -- as far as I can tell, this is better platform coverage than XMPP, and better feature parity within those clients since critical things like message IDs are actually baked into the spec.  I really suggest giving matrix a look.  There&amp;#x27;s a lot going right over there.</text></item><item><author>bad_user</author><text>You mean XMPP federation?&lt;p&gt;Nobody wants to implement that because companies like Slack, Atlassian, Google, Facebook, Microsoft, Apple, etc are interested in lock-in primarily.</text></item><item><author>ara4n</author><text>There&amp;#x27;s no harm in having loads of options - you just get a Darwinian survival of the fittest for which app works best. Competition is healthy.&lt;p&gt;The thing that sucks is that as end users we end up having all our chats and identity fragmented over all these different silos - be they selfhosted ones or proprietary SaaS. There&amp;#x27;s no way I&amp;#x27;ll rely on MatterMost or any of the above unless I can access my existing communities (be they on IRC, XMPP, Slack, HipChat or whatever); adding yet more fragmentation into the mix helps nobody.&lt;p&gt;This is why it&amp;#x27;s vital to have an open standard for decentralising the conversations between all these different islands that kills fragmentation whenever a new one pops up. And it&amp;#x27;s actually beneficial to new contenders like MatterMost as it could help them onboard users into their UX and app without having to start new conversations and contacts.&lt;p&gt;[Disclaimer: Matrix.org is such a standard, providing an open HTTP API for decentralised chatrooms, and I work on it.]</text></item><item><author>volent</author><text>I don&amp;#x27;t really get why there is so many Slack alternatives coming up these days.&lt;p&gt;On every post like this there is tons of comment linking to other Slack alternatives, it&amp;#x27;s not like this is gonna be _the_ Slack-alternative.&lt;p&gt;Here is a non exhaustive list :&lt;p&gt;RocketChat : &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9624737&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9624737&lt;/a&gt;&lt;p&gt;Let&amp;#x27;s Chat : &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9040841&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9040841&lt;/a&gt;&lt;p&gt;Friends : &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9461504&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9461504&lt;/a&gt;&lt;p&gt;Gitter : &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=6739074&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=6739074&lt;/a&gt;</text></item></parent_chain><comment><author>Flowdalic</author><text>You are absolutely right. I usually encourage people to get involved in improving the (XMPP) situation.&lt;p&gt;Just last week I submitted a XEP for unique stanza IDs to the XSF [1], which will most likely be the base for IDs in MAM and other protocols. I guess that&amp;#x27;s the light reading you want. :)&lt;p&gt;And yes, Carbons (XEP-280), in it&amp;#x27;s current state, also suck. I&amp;#x27;m working on a replacement XEP called &amp;quot;Message Routing 2.0 &amp;quot; (MR2): &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;geekplace.eu&amp;#x2F;xeps&amp;#x2F;xep-mr2&amp;#x2F;xep-mr2.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;geekplace.eu&amp;#x2F;xeps&amp;#x2F;xep-mr2&amp;#x2F;xep-mr2.html&lt;/a&gt; It&amp;#x27;s in an early draft state, but I think it addresses most, if not all, issues with carbons, improving the multi-device situation in XMPP somewhat (I don&amp;#x27;t care if it&amp;#x27;s MR2 or an improved version of carbons that makes the race).&lt;p&gt;&amp;gt; see how ridiculously difficult this makes the basic idea of &amp;quot;all clients should see the same picture&amp;quot;
Being involved in XMPP a bit, I get quite a few requests on how to implement WhatsApp&amp;#x2F;Hangouts like groupchats. And while the basic idea is quite simple, implementing it is a non-trivial task. But it can certainly be done. But we need more motivated developers and specification designers to get it done. While the XMPP community is just great, the count of activley involved people is quite small.&lt;p&gt;1: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;mail.jabber.org&amp;#x2F;pipermail&amp;#x2F;standards&amp;#x2F;2015-June&amp;#x2F;029865.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;mail.jabber.org&amp;#x2F;pipermail&amp;#x2F;standards&amp;#x2F;2015-June&amp;#x2F;029865....&lt;/a&gt;</text></comment>
<story><title>Mattermost: Open-source, on-premises, Slack alternative</title><url>http://www.mattermost.org/</url></story><parent_chain><item><author>heavenlyhash</author><text>Lots of people -- in that list, even -- started with XMPP based systems.  They all move away.  At first, I also thought this was an open and shut case of interest in lock-in.  Now, I&amp;#x27;m not going to say that isn&amp;#x27;t true, but it&amp;#x27;s also worth considering that XMPP... just isn&amp;#x27;t that good.&lt;p&gt;Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to admit: XMPP is... it&amp;#x27;s decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work.  I can&amp;#x27;t honestly fault anyone who started with XMPP and then rapidly started looking to get off.&lt;p&gt;Examples:&lt;p&gt;- unique message IDs? Absent. XEPs kind of provide; but I can&amp;#x27;t tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...).&lt;p&gt;- multi device? Oh. My. God. It&amp;#x27;s bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages.&lt;p&gt;- there&amp;#x27;s a concept of &amp;quot;message carbons&amp;quot; to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering.&lt;p&gt;Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of &amp;quot;all clients should see the same picture&amp;quot;.&lt;p&gt;Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it&amp;#x27;s all considered &amp;quot;extensions&amp;quot;. Stuff like message IDs fundamentally shouldn&amp;#x27;t be an extension because it&amp;#x27;s just too critical that all minimum-viable clients agree. You just can&amp;#x27;t build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features.&lt;p&gt;I want an open chat protocol.&lt;p&gt;I thought XMPP might be the one. Then I actually looked at it. Tried to write something with it.&lt;p&gt;XMPP is not prepared to be the one, in any sense at all except for legacy support. I have all the respect in the world for all the folks who put effort into trying to make an open chat standard, but... honestly, we need a stronger foundation than this.&lt;p&gt;(N.b. These complaints are a shameless repost from another not-very-old thread about chat where XMPP was also raised: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9718784&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9718784&lt;/a&gt; .)&lt;p&gt;I&amp;#x27;ve since looked at matrix.org ... and I&amp;#x27;m &lt;i&gt;really&lt;/i&gt; impressed.  The standard is completely reasonable.  It&amp;#x27;s the first federated chat standard I&amp;#x27;ve seen proposed that actually has loose timing systems that&amp;#x27;s both available during a partition and can reach consistency afterward (messages list their last-seen messages, and so act like vector clocks, an accepted good solution to problems in CAP territory).  You could actually take two systems with clock skew and have them reach a single, reconciled view of the world, even after netsplits.  And practically speaking... man, go look at their list of clients.  Despite being a relatively young project, matrix has clients on every major platform -- as far as I can tell, this is better platform coverage than XMPP, and better feature parity within those clients since critical things like message IDs are actually baked into the spec.  I really suggest giving matrix a look.  There&amp;#x27;s a lot going right over there.</text></item><item><author>bad_user</author><text>You mean XMPP federation?&lt;p&gt;Nobody wants to implement that because companies like Slack, Atlassian, Google, Facebook, Microsoft, Apple, etc are interested in lock-in primarily.</text></item><item><author>ara4n</author><text>There&amp;#x27;s no harm in having loads of options - you just get a Darwinian survival of the fittest for which app works best. Competition is healthy.&lt;p&gt;The thing that sucks is that as end users we end up having all our chats and identity fragmented over all these different silos - be they selfhosted ones or proprietary SaaS. There&amp;#x27;s no way I&amp;#x27;ll rely on MatterMost or any of the above unless I can access my existing communities (be they on IRC, XMPP, Slack, HipChat or whatever); adding yet more fragmentation into the mix helps nobody.&lt;p&gt;This is why it&amp;#x27;s vital to have an open standard for decentralising the conversations between all these different islands that kills fragmentation whenever a new one pops up. And it&amp;#x27;s actually beneficial to new contenders like MatterMost as it could help them onboard users into their UX and app without having to start new conversations and contacts.&lt;p&gt;[Disclaimer: Matrix.org is such a standard, providing an open HTTP API for decentralised chatrooms, and I work on it.]</text></item><item><author>volent</author><text>I don&amp;#x27;t really get why there is so many Slack alternatives coming up these days.&lt;p&gt;On every post like this there is tons of comment linking to other Slack alternatives, it&amp;#x27;s not like this is gonna be _the_ Slack-alternative.&lt;p&gt;Here is a non exhaustive list :&lt;p&gt;RocketChat : &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9624737&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9624737&lt;/a&gt;&lt;p&gt;Let&amp;#x27;s Chat : &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9040841&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9040841&lt;/a&gt;&lt;p&gt;Friends : &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9461504&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=9461504&lt;/a&gt;&lt;p&gt;Gitter : &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=6739074&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=6739074&lt;/a&gt;</text></item></parent_chain><comment><author>lewisl9029</author><text>One thing I&amp;#x27;m curious about regarding matrix.org:&lt;p&gt;As a federated protocol, is there anything at all in the spec that would discourage someone from piggy-backing on the federation to acquire initial users, goodwill and a head-start on features, and then locking users in once they&amp;#x27;ve gained enough momentum by making proprietary modifications?&lt;p&gt;You know, the same tactic countless companies have pulled with XMPP?&lt;p&gt;I&amp;#x27;ve been eyeing matrix.org for quite a while now, but it seems to still lack a &lt;i&gt;&amp;quot;killer&amp;quot;&lt;/i&gt; client app. One that can at least match the features, polish, stability, usability and platform ubiquity of existing proprietary messaging apps, an app that can help matrix.org grow user mindshare and keep it.&lt;p&gt;The open source community just doesn&amp;#x27;t seem to do a very good job of churning out these kinds of consumer-oriented apps. And if some company ends up building such a &lt;i&gt;&amp;quot;killer&amp;quot;&lt;/i&gt; app for matrix.org and gains momentum, they&amp;#x27;d have some very sweet incentives to lock in their userbase.</text></comment>