Mattermost: Open-source, on-premises, Slack alternative(mattermost.org)
mattermost.org
Mattermost: Open-source, on-premises, Slack alternative
http://www.mattermost.org/
221 comments
It may be a perfect match, given that Slack has been created by a game dev team too:
https://en.wikipedia.org/wiki/Slack_Technologies#Initial_fun...
https://en.wikipedia.org/wiki/Slack_Technologies#Initial_fun...
It's rather funny how Stewart Butterfield keeps trying to build games, and ending up with social apps.
His first company, Ludicorp, tried to build an MMORPG called Game Neverending, which never launched, and they pivoted to create Flickr, apparently based on the same platform (which is why ".gne" URLs proliferated Flickr originally).
With Tiny Speck, he created Glitch, another MMORPG, which closed a little more than a year after launch. Tiny Speck then pivoted to launch Slack, based on a chat app they had built internally while developing their game.
His first company, Ludicorp, tried to build an MMORPG called Game Neverending, which never launched, and they pivoted to create Flickr, apparently based on the same platform (which is why ".gne" URLs proliferated Flickr originally).
With Tiny Speck, he created Glitch, another MMORPG, which closed a little more than a year after launch. Tiny Speck then pivoted to launch Slack, based on a chat app they had built internally while developing their game.
It makes sense, in a weird way. MMO's are such huge projects that developers are forced to create supporting subsystems to complete it (e.g. Image/asset processing and storage system - Flickr, in-game chat and collaboration system - Slack).
I'm impressed that Stewart Butterfield is able to look at these systems and recognize which ones could be a viable (and successful!) stand-alone product.
I'm impressed that Stewart Butterfield is able to look at these systems and recognize which ones could be a viable (and successful!) stand-alone product.
I'm not sure why that would be all that relevant though.
If they wanted to implement a chat feature into a game it might be easier to embed this, though I could be wrong? Or if they just want a tweakable and reusable chat service to be used in-house maybe?
With even the same argument of them building a HipChat or Flowdock clone.
> Don't want to troll you guys here, but if you're a video game company why are you spending so much time building a Slack clone?
I think a better perspective is that this is a tool they needed/wanted and built it - it's really no different than a map editor. Also some companies like Google have a X% time to work on a "personal" project during work hours - and this could be the result of that.
I think a better perspective is that this is a tool they needed/wanted and built it - it's really no different than a map editor. Also some companies like Google have a X% time to work on a "personal" project during work hours - and this could be the result of that.
Sounds like a lot of burndown on your non-core competency IMO, but thanks for releasing.
Not all companies track sprints by the hour. :) Dev times for AAA video games are in years, not months. After working for both web and game companies, I find the development mindset for each to be remarkably incompatible.
Have you noticed any other development differences between web and game companies? This would make a great blog post.
I've noticed one difference. Game companies locally are known as sweatshops. I've literally talked to their recruiters who laugh as they share stories about how some game dev. had his wife calling to ask if he could come home for a few hours because she hadn't seem him in a week.
They have this crazy idea called "crunch time" which seems to be the same thing as "all the time". Also, because so many people go into CS programs because they want to make games, game companies aren't forced to pay very high salaries.
They have this crazy idea called "crunch time" which seems to be the same thing as "all the time". Also, because so many people go into CS programs because they want to make games, game companies aren't forced to pay very high salaries.
I can't tell if you're aware of the coincidence, but did you know that Slack was a pivot from game development just like Stewart Butterfield's previous unicorn Flickr?
"Unicorn" is probably the silliest term of the year. But it degrades to meaninglessness if you include Flickr, which sold to Yahoo! in 2005, for $20MM.
Wow, I got reamed out pretty hard for absent-minded use of a trendy term without thinking about it too much.
In my mind Flickr is up there with the Instagrams and the Ubers of the world because it was a fucking amazing experience at the time. I never even considered the valuation, but Flickr was definitely unique in the UX it brought to the table. I think people forget what the landscape looked like then. Or maybe they just can't get past a knee-jerk reaction to hot-button terminology.
Either way, I think it's fascinating that not one but two companies from the founder of Slack were pivots from game companies, and that's exactly what the GP is complaining about in the clone. Anyone care to comment on that?
In my mind Flickr is up there with the Instagrams and the Ubers of the world because it was a fucking amazing experience at the time. I never even considered the valuation, but Flickr was definitely unique in the UX it brought to the table. I think people forget what the landscape looked like then. Or maybe they just can't get past a knee-jerk reaction to hot-button terminology.
Either way, I think it's fascinating that not one but two companies from the founder of Slack were pivots from game companies, and that's exactly what the GP is complaining about in the clone. Anyone care to comment on that?
> In my mind Flickr is up there with the Instagrams and the Ubers of the world because it was a fucking amazing experience at the time. I never even considered the valuation, but Flickr was definitely unique in the UX it brought to the table. I think people forget what the landscape looked like then. Or maybe they just can't get past a knee-jerk reaction to hot-button terminology.
Absolutely. They stagnated for a while, but when Flickr came out all the other popular photo sites would shrink your image down to a tiny low quality version, ads everywhere. Out of desperation I used to host my photos on a PHP-based gallery app I dropped as soon as I got a Flickr account.
Absolutely. They stagnated for a while, but when Flickr came out all the other popular photo sites would shrink your image down to a tiny low quality version, ads everywhere. Out of desperation I used to host my photos on a PHP-based gallery app I dropped as soon as I got a Flickr account.
Sorry, my comment wasn't meant to be snarky, but I can see how that's not clear.
I was just musing on the fact that (yes, I don't like the term, but also) "unicorn" was originally a label for startups with huge valuations, generally > $1B. It has mutated since then, but the idea that it would apply to Flickr seemed funny.
I was just musing on the fact that (yes, I don't like the term, but also) "unicorn" was originally a label for startups with huge valuations, generally > $1B. It has mutated since then, but the idea that it would apply to Flickr seemed funny.
I wasn't bothered by your comment actually, it was more that I was at -4 for what I believed to be at least a mildly interesting observation at its core.
Not defending the use of the term, but you have to look at acquisitions in the context of the time. Though $20m seems like nothing notable today, in the post bubble fallout it was a significant achievement.
> Though $20m seems like nothing notable today, in the post bubble fallout it was a significant achievement.
2005 is probably a bit beyond the "post bubble fallout" - nevertheless the previous year Yahoo spent $579M on Kelkoo and in 2003 (which is most definitely "post bubble fallout" era) they bought Overture Services for $1.6B[1].
Creating something that fetches $20M is certainly a success, but let's not pretend this is some amazing acquisition story on par with YouTube.
[1] https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitio...!
2005 is probably a bit beyond the "post bubble fallout" - nevertheless the previous year Yahoo spent $579M on Kelkoo and in 2003 (which is most definitely "post bubble fallout" era) they bought Overture Services for $1.6B[1].
Creating something that fetches $20M is certainly a success, but let's not pretend this is some amazing acquisition story on par with YouTube.
[1] https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitio...!
Text editors become mail clients. Game editors need chat clients. I see a pattern. Things want to talk to other things.
Their game was called 'Game neverending', never launched, how apropos.
They probably had to build similar stuff for some of their games perhaps.
What's wrong with that? Many great products started at companies which are not "supposed" to do that as their core business. Pivotal Tracker is one thing that immediately sprang to my mind. Why do you want to strictly limit what a company is working on, and potentially kill great ideas anyways. I believe as long as they're still functioning, their game development business is probably totally fine. The same applies to a person: I don't believe if you work on something as a full-time job you're then not allowed to have your hobbies, side projects(some of which are quite huge in scale) and personal interests. That would be horrible.
I don't really get why there is so many Slack alternatives coming up these days.
On every post like this there is tons of comment linking to other Slack alternatives, it's not like this is gonna be _the_ Slack-alternative.
Here is a non exhaustive list :
RocketChat : https://news.ycombinator.com/item?id=9624737
Let's Chat : https://news.ycombinator.com/item?id=9040841
Friends : https://news.ycombinator.com/item?id=9461504
Gitter : https://news.ycombinator.com/item?id=6739074
On every post like this there is tons of comment linking to other Slack alternatives, it's not like this is gonna be _the_ Slack-alternative.
Here is a non exhaustive list :
RocketChat : https://news.ycombinator.com/item?id=9624737
Let's Chat : https://news.ycombinator.com/item?id=9040841
Friends : https://news.ycombinator.com/item?id=9461504
Gitter : https://news.ycombinator.com/item?id=6739074
There'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.
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's no way I'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.
This is why it'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'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.
[Disclaimer: Matrix.org is such a standard, providing an open HTTP API for decentralised chatrooms, and I work on it.]
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's no way I'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.
This is why it'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'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.
[Disclaimer: Matrix.org is such a standard, providing an open HTTP API for decentralised chatrooms, and I work on it.]
You mean XMPP federation?
Nobody wants to implement that because companies like Slack, Atlassian, Google, Facebook, Microsoft, Apple, etc are interested in lock-in primarily.
Nobody wants to implement that because companies like Slack, Atlassian, Google, Facebook, Microsoft, Apple, etc are interested in lock-in primarily.
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'm not going to say that isn't true, but it's also worth considering that XMPP... just isn't that good.
Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to admit: XMPP is... it's decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work. I can't honestly fault anyone who started with XMPP and then rapidly started looking to get off.
Examples:
- unique message IDs? Absent. XEPs kind of provide; but I can'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...).
- multi device? Oh. My. God. It'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.
- there's a concept of "message carbons" 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.
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 "all clients should see the same picture".
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's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can'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.
I want an open chat protocol.
I thought XMPP might be the one. Then I actually looked at it. Tried to write something with it.
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.
(N.b. These complaints are a shameless repost from another not-very-old thread about chat where XMPP was also raised: https://news.ycombinator.com/item?id=9718784 .)
I've since looked at matrix.org ... and I'm really impressed. The standard is completely reasonable. It's the first federated chat standard I've seen proposed that actually has loose timing systems that'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's a lot going right over there.
Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to admit: XMPP is... it's decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work. I can't honestly fault anyone who started with XMPP and then rapidly started looking to get off.
Examples:
- unique message IDs? Absent. XEPs kind of provide; but I can'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...).
- multi device? Oh. My. God. It'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.
- there's a concept of "message carbons" 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.
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 "all clients should see the same picture".
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's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can'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.
I want an open chat protocol.
I thought XMPP might be the one. Then I actually looked at it. Tried to write something with it.
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.
(N.b. These complaints are a shameless repost from another not-very-old thread about chat where XMPP was also raised: https://news.ycombinator.com/item?id=9718784 .)
I've since looked at matrix.org ... and I'm really impressed. The standard is completely reasonable. It's the first federated chat standard I've seen proposed that actually has loose timing systems that'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's a lot going right over there.
You are absolutely right. I usually encourage people to get involved in improving the (XMPP) situation.
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's the light reading you want. :)
And yes, Carbons (XEP-280), in it's current state, also suck. I'm working on a replacement XEP called "Message Routing 2.0 " (MR2): http://geekplace.eu/xeps/xep-mr2/xep-mr2.html It'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't care if it's MR2 or an improved version of carbons that makes the race).
> see how ridiculously difficult this makes the basic idea of "all clients should see the same picture" Being involved in XMPP a bit, I get quite a few requests on how to implement WhatsApp/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.
1: http://mail.jabber.org/pipermail/standards/2015-June/029865....
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's the light reading you want. :)
And yes, Carbons (XEP-280), in it's current state, also suck. I'm working on a replacement XEP called "Message Routing 2.0 " (MR2): http://geekplace.eu/xeps/xep-mr2/xep-mr2.html It'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't care if it's MR2 or an improved version of carbons that makes the race).
> see how ridiculously difficult this makes the basic idea of "all clients should see the same picture" Being involved in XMPP a bit, I get quite a few requests on how to implement WhatsApp/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.
1: http://mail.jabber.org/pipermail/standards/2015-June/029865....
One thing I'm curious about regarding matrix.org:
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've gained enough momentum by making proprietary modifications?
You know, the same tactic countless companies have pulled with XMPP?
I've been eyeing matrix.org for quite a while now, but it seems to still lack a "killer" 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.
The open source community just doesn'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 "killer" app for matrix.org and gains momentum, they'd have some very sweet incentives to lock in their userbase.
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've gained enough momentum by making proprietary modifications?
You know, the same tactic countless companies have pulled with XMPP?
I've been eyeing matrix.org for quite a while now, but it seems to still lack a "killer" 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.
The open source community just doesn'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 "killer" app for matrix.org and gains momentum, they'd have some very sweet incentives to lock in their userbase.
Oh, in terms of the risk of federation causing lock-in: it's inevitable that folks will add domain-specific extensions to try to force people to use their platform. This is no different to me sending you an attachment over email in some proprietary vendor-specific format (e.g. .ppt) which obliges you to install PowerPoint to read it.
This can be used for both good and evil. The evil scenario is above - rather than using an open standard like ODF, it provides a route to promote vendor lock-in. The good scenario is that it provides extensibility for technology that simply isn't standardised yet, and gives vendors a way to differentiate their product. For instance, if Oculus jumped on Matrix and started using it to negotiate VR collaboration spaces, it almost certainly wouldn't work with any other vendor at first... but it's good news for end-users who get a cool feature which some day may be standardised across all of Matrix.
The bottom line is that as long as everyone implements the common base line use cases in an interoperable fashion (i.e. IM and VoIP), then vendors having freedom to put proprietary/experimental stuff on top is just a necessary evil... as long as they don't break the baseline. It's up to us as consumers to then encourage vendors to make their extensions standards rather than exploit them for vendor-lockin. It really is an identical situation to email and MIME.
This can be used for both good and evil. The evil scenario is above - rather than using an open standard like ODF, it provides a route to promote vendor lock-in. The good scenario is that it provides extensibility for technology that simply isn't standardised yet, and gives vendors a way to differentiate their product. For instance, if Oculus jumped on Matrix and started using it to negotiate VR collaboration spaces, it almost certainly wouldn't work with any other vendor at first... but it's good news for end-users who get a cool feature which some day may be standardised across all of Matrix.
The bottom line is that as long as everyone implements the common base line use cases in an interoperable fashion (i.e. IM and VoIP), then vendors having freedom to put proprietary/experimental stuff on top is just a necessary evil... as long as they don't break the baseline. It's up to us as consumers to then encourage vendors to make their extensions standards rather than exploit them for vendor-lockin. It really is an identical situation to email and MIME.
The example 'Matrix Console' iOS & Android apps are aesthetically very ugly, but still very functional and usable from a geek perspective. Meanwhile we're currently replacing the example Matrix Angular webapp with a Matrix React webapp which will improve the performance enormously.
In terms of polished UI/UX, we were hoping the community would fork the example apps and put the necessary polish and usability on them. Features should (almost) all be there, and we're doing our best on platform ubiquity.
However, as ex3ndr's comment below shows, there are people still creating their own per-app proprietary protocols rather than building on something like Matrix.
So in order to help bootstrap Matrix, am sure we'll end up building a killer client app sooner or later if nobody else does :)
In terms of polished UI/UX, we were hoping the community would fork the example apps and put the necessary polish and usability on them. Features should (almost) all be there, and we're doing our best on platform ubiquity.
However, as ex3ndr's comment below shows, there are people still creating their own per-app proprietary protocols rather than building on something like Matrix.
So in order to help bootstrap Matrix, am sure we'll end up building a killer client app sooner or later if nobody else does :)
Thank you for the detailed reply.
Glad to hear you guys have plans to build a client app if needed.
Regarding matrix home servers, are users expected to just trust that they won't read/leak/share their private data (contacts, chat history, profile info, etc)? Or do home servers store user data in an encrypted form so users can just treat them as a zero-knowledge storage server without having to trust them at all? (I couldn't find storage encryption mentioned anywhere in the spec or anywhere on the faq, so I'm assuming it's the former)
If it is the former, are there any plans to move towards the latter? As we've seen in the case of email, even federated services tend to eventually gravitate towards a usage model where a handful of very large service providers service an overwhelming majority of users. I don't think allowing these service providers access to the private data of all of their users is in the best interest of the matrix community.
Glad to hear you guys have plans to build a client app if needed.
Regarding matrix home servers, are users expected to just trust that they won't read/leak/share their private data (contacts, chat history, profile info, etc)? Or do home servers store user data in an encrypted form so users can just treat them as a zero-knowledge storage server without having to trust them at all? (I couldn't find storage encryption mentioned anywhere in the spec or anywhere on the faq, so I'm assuming it's the former)
If it is the former, are there any plans to move towards the latter? As we've seen in the case of email, even federated services tend to eventually gravitate towards a usage model where a handful of very large service providers service an overwhelming majority of users. I don't think allowing these service providers access to the private data of all of their users is in the best interest of the matrix community.
For now, it's an implementation detail (rather than specced) as to how homeservers persist their state. The synapse implementation stores all data unencrypted in sqlite or postgres - /however/ that data may be end-to-end encrypted (we are releasing our e2e support over the course of this week - the first bit of the puzzle can be seen at http://github.com/matrix-org/olm). We should probably store all data AESed in the db to avoid casual snooping too.
This doesn't obfuscate metadata like room membership or profile data however; but fixing this is Hard. For now it's just a fact of life that Matrix servers have visibility on communication metadata - i.e. the identities of who talks to who, and when, and with what kind of event. In future we may support better privacy preserving semantics by evolving the federation architecture: eg running homeservers on clients and using Pond-style hidden Tor services for message transport, or layering on GNUnet as a transport. We've tried to design Matrix to support this sort of evolution, but right now today Matrix provides the same level of metadata privacy ss (say) an IMAP or SMTP server.
This doesn't obfuscate metadata like room membership or profile data however; but fixing this is Hard. For now it's just a fact of life that Matrix servers have visibility on communication metadata - i.e. the identities of who talks to who, and when, and with what kind of event. In future we may support better privacy preserving semantics by evolving the federation architecture: eg running homeservers on clients and using Pond-style hidden Tor services for message transport, or layering on GNUnet as a transport. We've tried to design Matrix to support this sort of evolution, but right now today Matrix provides the same level of metadata privacy ss (say) an IMAP or SMTP server.
Can't agree more. That's why we started our project with fresh and new protocol for messaging with implementing all required stuff in it's core, not extensions.
I'm not sure that creating a new vendor-specific protocol without federation or cross-vendor interoperability really helps anyone but you ;)
Hey, thanks for your rant, very informative :-)
As a user, I don't care which standard gets implemented, I just want one now.
As a user, I don't care which standard gets implemented, I just want one now.
Agreed :) Though I've been playing with matrix's stuff, I'm not wearing anybody's jerseys; I just want a standard.
I have to share those impressions of XMPP because I'm afraid XMPP is very much "good enough being the enemy of good". I used to be in the camp of "what good is [new standard X], didn't they read about XMPP?" and now... well, now I see that there's a reason XMPP adoption is faltering, and it really does require going back to the drawing board. XMPP was great for the time, but at this point I also don't want it to take steam away from folks who are making a real shot at a better standard.
I have to share those impressions of XMPP because I'm afraid XMPP is very much "good enough being the enemy of good". I used to be in the camp of "what good is [new standard X], didn't they read about XMPP?" and now... well, now I see that there's a reason XMPP adoption is faltering, and it really does require going back to the drawing board. XMPP was great for the time, but at this point I also don't want it to take steam away from folks who are making a real shot at a better standard.
All the flaws you mentioned can be solved. We solved them in ejabberd.
Matrix do have a much bigger marketing budget than the XSF, it's true. They fly their employees all over the globe, and appear to have a constant stream of FUD on tap about XMPP, presumably because it's their strongest competitor. Last I saw, though, it's got a thumping great single-point-of-control in the middle, firmly under their corporate grasp. Nothing too critical, though, only your identity. (Looking at the FAQ, the "Can I run my own Identity Server?" question is simply missing, but I can answer that one: No)
XMPP's primary distinction is that all services are fully partitioned by domain. The only shared state - and I use this term very loosely - is in subscription data, which is long term. (By subscription data, I'm intending to mean the roster, pubsub, and also MUC chatroom occupancy). Matrix attempts to share considerably more state, acting much more like a single chat service scattered across multiple servers, but due to the centralized and privileged identity servers, there's a significant loss of autonomy in the system. Important to note, an XMPPservice on a single domain can be spread across multiple physical servers, fully sharing state, in which case you're well into the territory of vector clocking and CAP theorums, but that's an internal matter for your service and doesn't affect the inter-domain federation at all.
In layman's terms, you can run an XMPP service without reference to any external system - although federation would need you to reference DNS. Running a Matrix server leaves you somewhat under the control of Matrix, which despite appearances is just a branding for a commercial outfit.
Well, that, and XMPP is an open standard according to a definition we didn't just make up as part of our marketing. (see OpenStand.org)
So first off, it may be useful to note that when looking for a universal, interoperable standard for text chat, the armed forces around the world went for XMPP. This based on its reliability and handling of low bandwidth situations (much, much, MUCH lower bandwidth than mobile). So when you say XMPP doesn't support your notion of an MVP, it's worth noting it really is just that - your notion. That doesn't make you wrong, but it may be that your focus is different from other people's.
And as a second point, when considering writing something on the web, you (thankfully) don't have to implement JavaScript. Or HTML. Or CSS. Or, thank heavens, HTTP. Do you even know what happens in HTTP? Clearly not, otherwise you'd be a gibbering wreck - it's about as badly designed as a protocol can be and still work. And don't get me started on TCP; nobody gets that right.
So really, if you're implementing something using XMPP, please don't leap in at the low level - just use one of the many libraries for your chosen platforms.
Next: Unique message identifiers are an interesting topic, and you've referenced several XEPs that don't address the problem. One issue is that what's needed varies in different situations - generally, a short-term scoped identifier is good enough, but it's fair to say that's not always the case. The tuple of <from,to,id> is good enough for this, though clients aren't mandated to send an identifier. It's not even clear to me that we need global stable persistent single-valued identifiers, but despite there being no use-case explained to me where this is required, I'm aware it's a popular solution some undefined problem.
Worth noting, too, that XEP-0198 and XEP-0184, though often confused as addressing the same problem, actually address entirely different ones. '198 addresses link reliability, tackling the two generals problem. '184 addresses end to end acks. You end up with acks in both, but 184's can be out of order, and 198 allows session resumption and retransmissions, which addresses the same cases you identify with vector clocks between domains. Your library should handle all this for you, and just note if a message is lost.
Carbons you have entirely wrong, sorry. It does not involve "re-sending your messages back to the server", it just allows non-priority clients to get copies of all messages. The only oddity is that the copies are just that - they're not duplicates. This allows the client being copied to identify that the messages are going to a different device. Which device is usually based on "priority", though different servers can do things slightly differently. Despite this, it doesn't have anything to do with message traffic. And it's not random.
However, clients typically respond to the device which sent the message - but if the sender has moved devices, they'll get a carbon. And yes, there is a massive "if supported" right there, but there are desktop clients that do.
In fact, we don't handle the "every device has the same view of the universe" concept - you're right - we handle the "every device knows the state of every other device". It's functionally identical, but a slightly richer view.
So, let's rewind.
The XSF doesn't write software, though there are many libraries out there. We're working on Push, mostly to cover Apple's platform where long-running sessions are prohibited - this despite the fact that on Android, clients like Yaxim or Conversations don't excessively use power.
The XSF also doesn't do the levels of social media advertising that Matrix does. This is becoming increasingly problematic for us as a community, because Matrix are explicitly targetting XMPP with things that are simply untrue.
Most of the problems you identify are actually solved at the protocol layer. They really are. And it's not as bad a solution as you imply, either - in fact, the solutions to multi-device messaging and archiving are pretty good, and more based on "every device knows about the other devices" rather than "every device is treated identically", which is interesting in and of itself.
Oh, and when I said low bandwidth? XMPP is routinely used over 2400bps SATCOM links with 30s latency, but it'll run lower. Try 9 bits per second, half-duplex, with 2 minutes link turnaround.
XMPP's primary distinction is that all services are fully partitioned by domain. The only shared state - and I use this term very loosely - is in subscription data, which is long term. (By subscription data, I'm intending to mean the roster, pubsub, and also MUC chatroom occupancy). Matrix attempts to share considerably more state, acting much more like a single chat service scattered across multiple servers, but due to the centralized and privileged identity servers, there's a significant loss of autonomy in the system. Important to note, an XMPPservice on a single domain can be spread across multiple physical servers, fully sharing state, in which case you're well into the territory of vector clocking and CAP theorums, but that's an internal matter for your service and doesn't affect the inter-domain federation at all.
In layman's terms, you can run an XMPP service without reference to any external system - although federation would need you to reference DNS. Running a Matrix server leaves you somewhat under the control of Matrix, which despite appearances is just a branding for a commercial outfit.
Well, that, and XMPP is an open standard according to a definition we didn't just make up as part of our marketing. (see OpenStand.org)
So first off, it may be useful to note that when looking for a universal, interoperable standard for text chat, the armed forces around the world went for XMPP. This based on its reliability and handling of low bandwidth situations (much, much, MUCH lower bandwidth than mobile). So when you say XMPP doesn't support your notion of an MVP, it's worth noting it really is just that - your notion. That doesn't make you wrong, but it may be that your focus is different from other people's.
And as a second point, when considering writing something on the web, you (thankfully) don't have to implement JavaScript. Or HTML. Or CSS. Or, thank heavens, HTTP. Do you even know what happens in HTTP? Clearly not, otherwise you'd be a gibbering wreck - it's about as badly designed as a protocol can be and still work. And don't get me started on TCP; nobody gets that right.
So really, if you're implementing something using XMPP, please don't leap in at the low level - just use one of the many libraries for your chosen platforms.
Next: Unique message identifiers are an interesting topic, and you've referenced several XEPs that don't address the problem. One issue is that what's needed varies in different situations - generally, a short-term scoped identifier is good enough, but it's fair to say that's not always the case. The tuple of <from,to,id> is good enough for this, though clients aren't mandated to send an identifier. It's not even clear to me that we need global stable persistent single-valued identifiers, but despite there being no use-case explained to me where this is required, I'm aware it's a popular solution some undefined problem.
Worth noting, too, that XEP-0198 and XEP-0184, though often confused as addressing the same problem, actually address entirely different ones. '198 addresses link reliability, tackling the two generals problem. '184 addresses end to end acks. You end up with acks in both, but 184's can be out of order, and 198 allows session resumption and retransmissions, which addresses the same cases you identify with vector clocks between domains. Your library should handle all this for you, and just note if a message is lost.
Carbons you have entirely wrong, sorry. It does not involve "re-sending your messages back to the server", it just allows non-priority clients to get copies of all messages. The only oddity is that the copies are just that - they're not duplicates. This allows the client being copied to identify that the messages are going to a different device. Which device is usually based on "priority", though different servers can do things slightly differently. Despite this, it doesn't have anything to do with message traffic. And it's not random.
However, clients typically respond to the device which sent the message - but if the sender has moved devices, they'll get a carbon. And yes, there is a massive "if supported" right there, but there are desktop clients that do.
In fact, we don't handle the "every device has the same view of the universe" concept - you're right - we handle the "every device knows the state of every other device". It's functionally identical, but a slightly richer view.
So, let's rewind.
The XSF doesn't write software, though there are many libraries out there. We're working on Push, mostly to cover Apple's platform where long-running sessions are prohibited - this despite the fact that on Android, clients like Yaxim or Conversations don't excessively use power.
The XSF also doesn't do the levels of social media advertising that Matrix does. This is becoming increasingly problematic for us as a community, because Matrix are explicitly targetting XMPP with things that are simply untrue.
Most of the problems you identify are actually solved at the protocol layer. They really are. And it's not as bad a solution as you imply, either - in fact, the solutions to multi-device messaging and archiving are pretty good, and more based on "every device knows about the other devices" rather than "every device is treated identically", which is interesting in and of itself.
Oh, and when I said low bandwidth? XMPP is routinely used over 2400bps SATCOM links with 30s latency, but it'll run lower. Try 9 bits per second, half-duplex, with 2 minutes link turnaround.
heavenlyhash: I think you struck a nerve ;)
Dave: yes, the Matrix 3rd party ID to Matrix-ID mapping service is currently logically centralised. The good news is that the service is entirely optional and you don't have to use it, and indeed in practice today nobody does: as of today everyone uses Matrix IDs to talk to each other. Matrix IDs themselves are completely decentralised, just like Jabber IDs, and are indeed fully partitioned by domain. I'm afraid you're the one shamelessly spreading the FUD here :D That said, if you have suggestions on how to decentralise a 3rd party ID to JID or Matrix ID mapping database, we'd love to collaborate on it, given the user discovery problem is an open issue for both XMPP and Matrix.
In terms of whether XMPP and Matrix are competitors: personally, I don't think of it that way. They have utterly different semantics and features. Matrix is fundamentally a decentralised object database with pubsub; XMPP is an extensible message-passing system. It might be worthwhile trying to play nice together rather than flaming each other - for instance, one of the folks in the Matrix community is writing an XMPP<->Matrix bridge that could benefit both ecosystems.
I'd also point out that there are loads of chat use cases where XMPP is currently miles better than Matrix - Matrix is inherently a heavier protocol due to all the state synchronisation, and if you want to just chuck messages around the place then I'm sure there are super-speedy mature XMPP servers that let you do so.
The idea that Matrix is branding for a commercial outfit is pretty ridiculous for anyone who's actually spoken to or worked with us :) I guess we're lucky that we've got corporate sponsorship to let us run around and try to tell folks that we exist, but the whole project is entirely transparent and open in every sense of the word I can imagine. Please stop hating and consider embracing the existence of a complementary open initiative rather than getting all defensive all the time...
Dave: yes, the Matrix 3rd party ID to Matrix-ID mapping service is currently logically centralised. The good news is that the service is entirely optional and you don't have to use it, and indeed in practice today nobody does: as of today everyone uses Matrix IDs to talk to each other. Matrix IDs themselves are completely decentralised, just like Jabber IDs, and are indeed fully partitioned by domain. I'm afraid you're the one shamelessly spreading the FUD here :D That said, if you have suggestions on how to decentralise a 3rd party ID to JID or Matrix ID mapping database, we'd love to collaborate on it, given the user discovery problem is an open issue for both XMPP and Matrix.
In terms of whether XMPP and Matrix are competitors: personally, I don't think of it that way. They have utterly different semantics and features. Matrix is fundamentally a decentralised object database with pubsub; XMPP is an extensible message-passing system. It might be worthwhile trying to play nice together rather than flaming each other - for instance, one of the folks in the Matrix community is writing an XMPP<->Matrix bridge that could benefit both ecosystems.
I'd also point out that there are loads of chat use cases where XMPP is currently miles better than Matrix - Matrix is inherently a heavier protocol due to all the state synchronisation, and if you want to just chuck messages around the place then I'm sure there are super-speedy mature XMPP servers that let you do so.
The idea that Matrix is branding for a commercial outfit is pretty ridiculous for anyone who's actually spoken to or worked with us :) I guess we're lucky that we've got corporate sponsorship to let us run around and try to tell folks that we exist, but the whole project is entirely transparent and open in every sense of the word I can imagine. Please stop hating and consider embracing the existence of a complementary open initiative rather than getting all defensive all the time...
OK, so your website claims that identity mapping is an integral key feature, so if I'm spreading FUD I apologise for repeating what's on your website.
As to whether XMPP and Matrix are competitors, you make direct comparisons between them (with incorrect assertions that have been pointed out to you before), and since you attack XMPP constantly on Twitter et al, I take it you think it is a threat.
Specifically, from your website's FAQ: - There's around four or five XMPP/Web implementations allowing you to easily speak XMPP from a browser, but the two most popular with web developers seem to be stanza.io and xmpp-ftw - the latter is JSON objects via HTTP/Websocket. - Most server implementations cluster, so a chatroom is highly available across multiple physical servers within the same domain. This latter restriction can be avoided using FMUC. - Hedging your comments with "(without extensions)" is crass, since there are many extensions that have very wide support. - Talking about a minimal baseline is at best ignorant, at worst deliberately misleading. Chatrooms aren't in our baseline, but that doesn't mean we should ignore them. - "Not particularly suited to mobile". We've actively worked on push recently, but on Android it's really optional. As for bandwidth efficiency, you use HTTP, so that's laughable - as noted above, stanzas go across HF radio in their native format just fine.
Yes, you can chuck messages around fast in XMPP. You can also chuck messages through pubsub systems very fast in XMPP.
So Matrix is a brand with no legal entity behind it, where the people operating it and controlling the specification seem to be entirely employed by the same company who owns the domain and sponsors an extensive publicity campaign? I shall never suggest it's merely branding for a commercial outfit again, my deepest apologies for having clearly misunderstood the situation.
As for getting defensive, I admit that too, but it's quite common when being attacked.
As to whether XMPP and Matrix are competitors, you make direct comparisons between them (with incorrect assertions that have been pointed out to you before), and since you attack XMPP constantly on Twitter et al, I take it you think it is a threat.
Specifically, from your website's FAQ: - There's around four or five XMPP/Web implementations allowing you to easily speak XMPP from a browser, but the two most popular with web developers seem to be stanza.io and xmpp-ftw - the latter is JSON objects via HTTP/Websocket. - Most server implementations cluster, so a chatroom is highly available across multiple physical servers within the same domain. This latter restriction can be avoided using FMUC. - Hedging your comments with "(without extensions)" is crass, since there are many extensions that have very wide support. - Talking about a minimal baseline is at best ignorant, at worst deliberately misleading. Chatrooms aren't in our baseline, but that doesn't mean we should ignore them. - "Not particularly suited to mobile". We've actively worked on push recently, but on Android it's really optional. As for bandwidth efficiency, you use HTTP, so that's laughable - as noted above, stanzas go across HF radio in their native format just fine.
Yes, you can chuck messages around fast in XMPP. You can also chuck messages through pubsub systems very fast in XMPP.
So Matrix is a brand with no legal entity behind it, where the people operating it and controlling the specification seem to be entirely employed by the same company who owns the domain and sponsors an extensive publicity campaign? I shall never suggest it's merely branding for a commercial outfit again, my deepest apologies for having clearly misunderstood the situation.
As for getting defensive, I admit that too, but it's quite common when being attacked.
I'm pretty sure we don't claim identity mapping anywhere as an integral key feature; if we do, it's a mistake. We always decoupled the identity mapping layer from the core messaging layer to avoid the Hard Problem of decentralised identity mapping blocking the core protocol, and we haven't even specified it yet (that chapter of the spec is blank).
In terms of whether we've been doing some kind of Evil Disinformation Campaign against XMPP, looking at https://twitter.com/search?q=%40matrixdotorg%20xmpp&src=typd... if anything it seems like we're pretty supportive of XMPP: "@usetalky stanza.io looks lovely.", "@Nyssen11 converse looks pretty. we (or someone) will write an xmpp s2s <--> Matrix bridge soon, i'm sure.", "For sure XMPP is doing cool new stuff too - FMUC, XMPP-FTW, Buddycloud etc." etc etc. We even promote XMPP alongside Matrix: "Metadata privacy & federation with legacy networks are mutex. If you want metadata privacy @GNUnet ftw. For fed, Matrix or XMPP?"
The only valid beef I'm seeing is https://twitter.com/ckoehncke/status/588341851360518144/phot... which missed that XSF had published a Push XEP a few weeks earlier (sorry!), and ".@rikardlinde @davewiner Matrix is pure HTTP & decentralised convo history: no single silo/point of control. Jabber MUCs = single chatserver", which was admittedly ambiguous and misleading thanks to the 160 char limit and I subsequently clarified; the intention was to point out that MUCs = single logical chatserver locked to a single domain (ignoring FMUCs).
In terms of the FAQ - as per our current twitter convo I'm updating it in realtime to incorporate your POV.
In terms of whether we are a Nefarious Corporate Conspiracy: We're in the process currently of splitting out Matrix.org as an independent UK Limited By Guarantee company with not-for-profit statutes of incorporation to act as the neutral guardian of the Matrix standard. I guess this is a bit like how IBM split off the Eclipse brand into being the proper Eclipse Foundation. So yes, from my pov we're not 'branding for a commercial outfit', given 100% of the IP for the project is permissive-licensed opensource and the project is non-profit rather than commercial. Meanwhile, increasing amounts of the Matrix ecosystem are being contributed by the community (like the aforementioned XMPP<->Matrix bridge ;) Anyway, this will all be clearer once we have our separate legal entity - apology accepted for misunderstanding the situation :D
In terms of whether we've been doing some kind of Evil Disinformation Campaign against XMPP, looking at https://twitter.com/search?q=%40matrixdotorg%20xmpp&src=typd... if anything it seems like we're pretty supportive of XMPP: "@usetalky stanza.io looks lovely.", "@Nyssen11 converse looks pretty. we (or someone) will write an xmpp s2s <--> Matrix bridge soon, i'm sure.", "For sure XMPP is doing cool new stuff too - FMUC, XMPP-FTW, Buddycloud etc." etc etc. We even promote XMPP alongside Matrix: "Metadata privacy & federation with legacy networks are mutex. If you want metadata privacy @GNUnet ftw. For fed, Matrix or XMPP?"
The only valid beef I'm seeing is https://twitter.com/ckoehncke/status/588341851360518144/phot... which missed that XSF had published a Push XEP a few weeks earlier (sorry!), and ".@rikardlinde @davewiner Matrix is pure HTTP & decentralised convo history: no single silo/point of control. Jabber MUCs = single chatserver", which was admittedly ambiguous and misleading thanks to the 160 char limit and I subsequently clarified; the intention was to point out that MUCs = single logical chatserver locked to a single domain (ignoring FMUCs).
In terms of the FAQ - as per our current twitter convo I'm updating it in realtime to incorporate your POV.
In terms of whether we are a Nefarious Corporate Conspiracy: We're in the process currently of splitting out Matrix.org as an independent UK Limited By Guarantee company with not-for-profit statutes of incorporation to act as the neutral guardian of the Matrix standard. I guess this is a bit like how IBM split off the Eclipse brand into being the proper Eclipse Foundation. So yes, from my pov we're not 'branding for a commercial outfit', given 100% of the IP for the project is permissive-licensed opensource and the project is non-profit rather than commercial. Meanwhile, increasing amounts of the Matrix ecosystem are being contributed by the community (like the aforementioned XMPP<->Matrix bridge ;) Anyway, this will all be clearer once we have our separate legal entity - apology accepted for misunderstanding the situation :D
http://matrix.org/docs/spec/#identity
""" Users in Matrix are identified via their matrix user ID (MXID). However, existing 3rd party ID namespaces can also be used in order to identify Matrix users. A Matrix "Identity" describes both the user ID and any other existing IDs from third party namespaces linked to their account. Matrix users can link third-party IDs (3PIDs) such as email addresses, social network accounts and phone numbers to their user ID. Linking 3PIDs creates a mapping from a 3PID to a user ID. This mapping can then be used by Matrix users in order to discover the MXIDs of their contacts. In order to ensure that the mapping from 3PID to user ID is genuine, a globally federated cluster of trusted "Identity Servers" (IS) are used to verify the 3PID and persist and replicate the mappings. Usage of an IS is not required in order for a client application to be part of the Matrix ecosystem. However, without one clients will not be able to look up user IDs using 3PIDs. """
OK, so aside from that last paragraph, that reads very integral. If it's just a case of "you have an identity at a domain" by default, and the 3PIDs are all an extension^Woptional-feature-that's-part-of-the-baseline, then what's the "strong identity system" you claim XMPP is lacking?
Actually if you read through that Twitter search, you see a bunch of XMPP folk getting annoyed at you for "half-truths, as usual", you referring to XMPP as a failure, you claiming that only the baseline counts, you claiming that MUC - universally and interoperably supported in every server (and every client that wants it) - is fragmented.
If this is you being supportive, I'd hate to see your actual disinformation campaigns.
Now, if you actually want a constructive conversation, that's great, but trolling just isn't the way to do that.
If you'd like a case where I suspect that Matrix models better, it's that ad-hoc, "ungoverned" multiparty chats work better in Matrix than XMPP.
That's because XMPP's multi-user chat model is (intentionally) based around IRC-channel-like models, where there's a single identity and authority. As I understand Matrix (and I don't claim expertise here), Matrix instead models a multi-party chat as simply a conversation involving multiple parties.
""" Users in Matrix are identified via their matrix user ID (MXID). However, existing 3rd party ID namespaces can also be used in order to identify Matrix users. A Matrix "Identity" describes both the user ID and any other existing IDs from third party namespaces linked to their account. Matrix users can link third-party IDs (3PIDs) such as email addresses, social network accounts and phone numbers to their user ID. Linking 3PIDs creates a mapping from a 3PID to a user ID. This mapping can then be used by Matrix users in order to discover the MXIDs of their contacts. In order to ensure that the mapping from 3PID to user ID is genuine, a globally federated cluster of trusted "Identity Servers" (IS) are used to verify the 3PID and persist and replicate the mappings. Usage of an IS is not required in order for a client application to be part of the Matrix ecosystem. However, without one clients will not be able to look up user IDs using 3PIDs. """
OK, so aside from that last paragraph, that reads very integral. If it's just a case of "you have an identity at a domain" by default, and the 3PIDs are all an extension^Woptional-feature-that's-part-of-the-baseline, then what's the "strong identity system" you claim XMPP is lacking?
Actually if you read through that Twitter search, you see a bunch of XMPP folk getting annoyed at you for "half-truths, as usual", you referring to XMPP as a failure, you claiming that only the baseline counts, you claiming that MUC - universally and interoperably supported in every server (and every client that wants it) - is fragmented.
If this is you being supportive, I'd hate to see your actual disinformation campaigns.
Now, if you actually want a constructive conversation, that's great, but trolling just isn't the way to do that.
If you'd like a case where I suspect that Matrix models better, it's that ad-hoc, "ungoverned" multiparty chats work better in Matrix than XMPP.
That's because XMPP's multi-user chat model is (intentionally) based around IRC-channel-like models, where there's a single identity and authority. As I understand Matrix (and I don't claim expertise here), Matrix instead models a multi-party chat as simply a conversation involving multiple parties.
As the spec says, the ID service is optional. We haven't even bothered speccing it because the current logically-centralised thing is placeholder until we find a good decentralised solution. "Strong identity system" simply refers to mandating public key infrastructure both for servers and clients. For servers it's implemented via perspectives as per http://matrix.org/docs/spec/#retrieving-server-keys. For clients it's currently being defined for our new E2E stuff; we'll publish the key management APIs over the next few weeks.
I'm afraid I do believe that XMPP has failed in providing a ubiquitous (i.e. as ubiquitous as the web or email) open federated ecosystem for realtime comms, otherwise we wouldn't have tried to build Matrix. Obviously we may fail too, but hey, might as well try. Sorry if you consider this opinion trolling :)
In terms of "only the baseline counts" or "MUC is fragmented", I'm either mis-communicating or you're misunderstanding. I do think XMPP suffers from too low a baseline of functionality (as do others on this thread seemingly), and I think that the various alternative group chat technologies on XMPP (e.g. MUC v FMUC v Buddycloud) between them cause fragmentation, in that conversations can get stuck in one protocol inaccessible to another (please correct me if I'm wrong).
And yes, Matrix models multi-user chat as 'simply' a distributed datastructure replicated over multiple servers with eventual consistency, using decentralised ACLs to maintain authority in the chat.
I'm afraid I do believe that XMPP has failed in providing a ubiquitous (i.e. as ubiquitous as the web or email) open federated ecosystem for realtime comms, otherwise we wouldn't have tried to build Matrix. Obviously we may fail too, but hey, might as well try. Sorry if you consider this opinion trolling :)
In terms of "only the baseline counts" or "MUC is fragmented", I'm either mis-communicating or you're misunderstanding. I do think XMPP suffers from too low a baseline of functionality (as do others on this thread seemingly), and I think that the various alternative group chat technologies on XMPP (e.g. MUC v FMUC v Buddycloud) between them cause fragmentation, in that conversations can get stuck in one protocol inaccessible to another (please correct me if I'm wrong).
And yes, Matrix models multi-user chat as 'simply' a distributed datastructure replicated over multiple servers with eventual consistency, using decentralised ACLs to maintain authority in the chat.
"Nobody" is an exageration, since Gitter, RocketChat, Mattermost, Friends, and Let's chat DO want to implement that.
I hope the open source community learned a lesson with Slack and other offerings. The trick is the user experience. Slack is a trivial piece of code to reproduce (not their business).
I recently switched from a company using HipChat to a company using Slack, and the differences seem mostly cosmetic and immaterial.
Are the differences between these various chat programs big enough to affect user experience or productivity?
What distinguishes one from the next?
One of the biggest differences for us was the option for a self hosted solution with HipChat. Both companies are fairly open about accessing user communications without any sort of permission or audit trail. Being able to self host it ensures that Atlassian or Slack employees aren't dropping into our chats.
Check the fine print. Even with the self-hosted version, Atlassian is scraping the chat data for analytic purposes. This was confirmed by Atlassian support via a HIPPA audit at my last gig.
You mean that slick, plaid UI with neutral, low key colors doesn't enhance your productivity? That's the whole reason I moved from HipChat to Slack.
Mattermost team here,
We think choice is good, and open source reduces the cost of creating more choice.
We think choice is good, and open source reduces the cost of creating more choice.
I actually prefer todays web video to having to install RealPlayer, Quicktime, Windows Media Player, Flash player, Shockwave player just play video on the web.
Choice is not always good.
Choice is not always good.
Actually now you have the choice of web video utilizing codecs that came from all the companies producing the software you mentioned above, and the evolution from them to the capability we have today, be it codecs or browser support. the new openness of it created the choice you prefer now.
[deleted]
Choice itself is also a cost, beyond a certain point. The more alternatives, the harder it is to evaluate them all properly.
That's not really a problem, you just a number of them you can evaluate (say, 10), either from some recommendation list or randomly, and ignore the others. The end result will be the same as if those others hadn't existed at all.
It's like back in 2010 when everyone was building free / open source Basecamp clones.
Yeah whatever happened to all of those?
Whatever happened to Basecamp itself? I used to hear about it all the time...
Last I heard they had 6 million active users (vs 1 million in 2012).
... by what definition of active, and what definition of users? Surely you would define such a SaaS by revenue or number of customers rather than users, which allows you to fluff up your number by claiming every individual at every client organization is a user ... even if those accounts are automatically generated by some onboarding process then ignored.
So many slack alternatives are coming up because slack is really good. It's that simple.
...and because so few people apparently realise that's Slack's value is in the quality execution, which can be copied by a decent team (but takes a phenomenal team to beat).
I don't find slack to be particularly well executed. It's often obvious that I'm dealing with a (poorly executed, laggy) html UI.
It's segfaulted in JavaScriptCore on my machine. So apparently they've managed to combine the performance of HTML with all the security of C++.
Their success seems to be mostly a matter of not being as enterprisey as hipchat and being less geeky than IRC.
It's segfaulted in JavaScriptCore on my machine. So apparently they've managed to combine the performance of HTML with all the security of C++.
Their success seems to be mostly a matter of not being as enterprisey as hipchat and being less geeky than IRC.
Genuine question: what did/do they execute on so well? I've only read about them having a great launch strategy.
In my view; product design & build quality. Yammer were already doing most of what Slack does. Tiny Speck took that and UX'd the shit out of it until it was a joy to use.
Gotcha, it's the first corporate chat app I've used outside of Skype, so I guess I don't know how bad it was, ha. I've personally had trouble with how unintuitive Slack's UI can be sometimes, when it seems like they're just trying to find places for all their features. But it's gotten ridiculously better in their last redesign.
Has anyone used a self-hosted one they were satisfied with? Which one?
Let's chat looked great but we were a little put off by mongodb and something else that escapes my mind right now so we ended up sticking with OpenFire for our XMPP server / chat rooms for the time being although it certainly has it's share of bugs.
For XMPP there is Kaiwa
http://getkaiwa.com/
http://getkaiwa.com/
Ah, an XMPP server is a good choice for IM for us, although I can't get the team to stick around in the channels for very long. Maybe that's a culture problem, though.
I would blame UX there :) In my mind a collaboration tool should not be a burden, if people let it down, it means it's not appropriate. Hence the success of Slack: people realised collaboration can be made easy and real-time without being a pain.
And wrt self-hosted chat servers, you can have a look at some implementations of Matrix (http://matrix.org): there is an opensource a ref implementation of a server (https://github.com/matrix-org) and then a bunch of clients at different level of glossiness, for web, iOS and Android (http://matrix.org/blog/try-matrix-now/) available. Or you can build your own if you feel like it :) Fully decentralised and persistent communication.
No full blown collaboration tool but public & private chat rooms with the ability to exchange files and do 1:1 voice & video calls (group call is in the pipe).
And wrt self-hosted chat servers, you can have a look at some implementations of Matrix (http://matrix.org): there is an opensource a ref implementation of a server (https://github.com/matrix-org) and then a bunch of clients at different level of glossiness, for web, iOS and Android (http://matrix.org/blog/try-matrix-now/) available. Or you can build your own if you feel like it :) Fully decentralised and persistent communication.
No full blown collaboration tool but public & private chat rooms with the ability to exchange files and do 1:1 voice & video calls (group call is in the pipe).
I'd say it likely is a culture problem, the first thing all our developers, project managers and engineers do when they get to work is login to the chat server. Everyone has their clients (mostly Adium with a few running Pidgin / Empathy) set to auto-join a couple of rooms, we have one called #devops that most people join and then one per major product that people may be working on.
The thing is that we prefer to communicate one to one on IM. Everyone logs into the chat server, but they don't use rooms as much. That's probably because everyone is in separate teams, and each team prefers different ways of communication.
Any particular reason why you were put off by mongo?
IRC.
We are pretty happy with let's chat.
Hah, this is awesome to hear. Are you using it with ldap/kerberos auth?
ldap, works like a charm
Thank you, that looks very nice.
Probably the same reason there's a new javascript framework every week. Some people think it's cool and want to build their own.
For better or worse.
For better or worse.
I think when developers see a simple, successful product they say to themselves "hey, I could do that!" So we wind up with a thousand to-do apps. Slack is a step or two in complexity beyond a to-do app. Simply copying a product like slack is not that difficult. Building an "amazing" version of a product while re-inventing small details is the clever part.
For me, only Gitter makes perfect sense.
Because it's based on GitHub repositories, I can see why this should be used instead of Slack.
10,000 message limit for free version.
You might have sensitive information you need contained in your network.
It get's expensive very fast.
You might have sensitive information you need contained in your network.
It get's expensive very fast.
I guess it's because it looks like a pretty easy application to build.
'Looks like' being key there.
'Looks like' being key there.
Chat programs are the hello world programs of the era of the social web.
One of the reasons there are so many alternatives is that many of us have been begging Slack for a self-hosted version for over a year and they are completely ignoring our requests. We want to give them a lot of money but apparently they don't want it.
I don't think it would make much/any sense for Slack to deliver a self-hosted version. First, it is growing like crazy right now. And second, that would be a totally different animal in terms of coding, maintaining, supporting, marketing, etc.
A great RFC instead a dozen incompatible startups would be the best thing since IRC.
I'm not aware of any particular feature that doesn't fit into XMPP with a couple new namespaces at most.
And before you get too down on XMPP, bear in mind that anything that standardizes half-a-dozen chat clients will end up pretty nasty on its own, too. It all looks simple when you're a user of the client, but under the hood chat systems get... "interesting". In the apocryphal Chinese curse sense.
And before you get too down on XMPP, bear in mind that anything that standardizes half-a-dozen chat clients will end up pretty nasty on its own, too. It all looks simple when you're a user of the client, but under the hood chat systems get... "interesting". In the apocryphal Chinese curse sense.
The best thing since IRC is IRC.
Slack has the advantage of maintaining message history server-side instead of client-side, so you can catch up on things you missed without running a client in a screen session (or a bouncer, or a logger, or...). This functionality is part of the core protocol.
Is there a similar standard for IRC? If not, then IRC is serving a different use case.
Is there a similar standard for IRC? If not, then IRC is serving a different use case.
It's trivial to log IRC, but it is hard to integrate server-side log display and search with prebaked clients.
That's because Slack is slow. There are even more lightweight open source Slack alternatives described here: http://browsingthenet.blogspot.com/2015/05/slack-is-so-slow-...
As you have mentioned many chat system... We thought about adding chat module to our open source trello clone called Restyaboard http://restya.com/board/
Do you think if this will not be useful addition? Or what chat system among above will be useful to integrate?
Do you think if this will not be useful addition? Or what chat system among above will be useful to integrate?
Slack is non-optimal for open source projects because each project will require you to have yet another Slack account. It also isn't IRC-like. With Gitter, you can be on multiple projects at once in one client UI.
So different use cases mean a different product might be better. Particularly if business concerns limit how one can use existing products.
So different use cases mean a different product might be better. Particularly if business concerns limit how one can use existing products.
Anyone know which of these has an easy integration component for chatting with web visitors?
As long as Gitter was copying Stewart Butterfield, they should have named it "Gittr".
Slack's success inspires derivatives and, in this case, a direct copy. Review the screenshots.
Before you get excited about Mattermost as the hosted Slack you've been waiting for, think hard about the AGPL licensing.
Before you get excited about Mattermost as the hosted Slack you've been waiting for, think hard about the AGPL licensing.
Why would that be a problem?
I haven't worked for a company in four years that permits the installation of AGPL software because the ramifications are still unclear and largely untested. MongoDB asserts, for example, that just using MongoDB doesn't require you to do anything, even though the license text is in clear contradiction to the assertion. I do not think MongoDB understands its own license.
Chris DiBona has spoken in public about Google's reasons, but he was kind. I cannot discuss other experience I have publicly, so I'd simply suggest doing some research on the large unknowns in deployment of AGPL software underneath a proprietary Web service somewhere, and then think about all the integrations you'd wire up to something like a Slack derivative.
I am not a lawyer and would strongly suggest consulting one before using AGPL software anywhere in your infrastructure, at all.
Chris DiBona has spoken in public about Google's reasons, but he was kind. I cannot discuss other experience I have publicly, so I'd simply suggest doing some research on the large unknowns in deployment of AGPL software underneath a proprietary Web service somewhere, and then think about all the integrations you'd wire up to something like a Slack derivative.
I am not a lawyer and would strongly suggest consulting one before using AGPL software anywhere in your infrastructure, at all.
I don't understand you reasoning at all. What could be the problem with using a chat software that is released under AGPL?
Because almost certainly engineers will want to integrate an on-premises system into their existing system, and that will trigger the AGPL for all the systems that are network-connected to the AGPL system.
Unless you are sure that your engineers will know to not try to integrate the AGPL software with any of your existing systems, I agree that people should just stay away.
Unless you are sure that your engineers will know to not try to integrate the AGPL software with any of your existing systems, I agree that people should just stay away.
>Because almost certainly engineers will want to integrate an on-premises system into their existing system, and that will trigger the AGPL for all the systems that are network-connected to the AGPL system.
That's the FUD version.
The real version is that unless you are changing the source code (hint: not just writing a plugin using an externally facing API) and deploying it, you don't have to do shit.
That's the FUD version.
The real version is that unless you are changing the source code (hint: not just writing a plugin using an externally facing API) and deploying it, you don't have to do shit.
And you still don't have to do shit even if you are changing the source code, as long as you only deploy it internally, which doesn't count as redistribution.
I think you're all correct.
The key thing is MongoDB uses an AGPL _variant_ that has AGPL core and Apache 2.0 drivers. So you can run it in proprietary software if you're only calling the Apache 2.0 drivers and not modifying the AGPL part (MySQL is the grand-daddy of this variant model back to the days of GPLv2).
A number of other projects use the same pattern, and so does Mattermost. If you can run MongoDB there shouldn't be a licensing issue with Mattermost.
The key thing is MongoDB uses an AGPL _variant_ that has AGPL core and Apache 2.0 drivers. So you can run it in proprietary software if you're only calling the Apache 2.0 drivers and not modifying the AGPL part (MySQL is the grand-daddy of this variant model back to the days of GPLv2).
A number of other projects use the same pattern, and so does Mattermost. If you can run MongoDB there shouldn't be a licensing issue with Mattermost.
What do you mean by "trigger the AGPL for all the systems that are network-connected to the AGPL system"?
The AGPL requires that you offer to distribute the source code to derivative works you make of AGPLed code; and it requires that you make that offer to a) people you have distributed binaries to and b) people you permit to access that derivative work over a network.
I guess I can imagine someone arguing that, by integrating Mattermost (for example) with another system, you are thereby giving users of that other system access to your installation of Mattermost, and so you would be required to offer them the source to that installation of Mattermost. Is that what you mean by "trigger the AGPL"?
The AGPL requires that you offer to distribute the source code to derivative works you make of AGPLed code; and it requires that you make that offer to a) people you have distributed binaries to and b) people you permit to access that derivative work over a network.
I guess I can imagine someone arguing that, by integrating Mattermost (for example) with another system, you are thereby giving users of that other system access to your installation of Mattermost, and so you would be required to offer them the source to that installation of Mattermost. Is that what you mean by "trigger the AGPL"?
No it won't... It will at most trigger the AGPL for the integration off that system... which is it's proprietary no one will ever want... hence no one will ever sue you to release it.
Are Tinfoil hats on sale or something?
Are Tinfoil hats on sale or something?
No, just folks with a little more legal experience than "potentially and willfully violate the terms and spirit of a license because we assume nobody will ever sue us," which also doesn't scale beyond a team of two. Not enough people take license compliance seriously. (Your comment an example.)
Just to communicate the impact here, getting compliance wrong can result in significant legal liability. You and I are both unqualified to dismiss it or discuss it.
Just to communicate the impact here, getting compliance wrong can result in significant legal liability. You and I are both unqualified to dismiss it or discuss it.
... Okay if it isn't tinfoil hatery... show me the case law which proves me wrong?
Saying "I know a cautious lawyer" is just tautological BS.
Saying "I know a cautious lawyer" is just tautological BS.
I find it interesting that you're getting consistent downvotes for saying the same thing my startup's legal counsel has repeatedly said about the AGPL: Be extremely careful. Assume nothing and write defensively, because the nature of an "integration" is too vague to risk a company's infrastructure.
I get the impression others here are happily screwing around with AGPL integrations with nothing to lose.
I get the impression others here are happily screwing around with AGPL integrations with nothing to lose.
I wonder what the lawyer would say about a startup agreeing to EULA's in gmail or iphone/android. Im sure there is not vague terms in those contracts, and that customer emails is perfectly safe to be stored there with no liability risk to the company.
I only suspect, but I think that vague terms in contracts is less of an issue when there has been no court cases involving companies that followed standard practices regarding compliance.
I only suspect, but I think that vague terms in contracts is less of an issue when there has been no court cases involving companies that followed standard practices regarding compliance.
It'll only trigger the AGPL if you make it available to outside users. Internal use doesn't count as redistribution for any of the *GPL licenses.
Well, the ``license.txt``available at the GitHub repository states that any enhancement made to the server must shared back with the community. So, even if you are using an enhanced version internally, you must redistribute it publicly.
Still its not clear that file can compel someone to even reveal what they do internally. Its an empty promise.
Yeah but if, for any reason, your company gets sued because they violated the AGPL license you're probably fucked.
> Teams who can’t use SaaS rely on cryptic, decades-old technologies. As an example, the US Army uses myIRC to order missile strikes
"myIRC" doesn't exist. The name of the protocol is IRC. The name of a popular Windows client is mIRC. WikiLeaks called their leak "mIRC logs," which is where this trope came from.
The United States military (not just the Army) uses Internet Relay Chat for a whole lot of C2. It runs on a network, both IRC and IP, dedicated to the purpose. Given how long IRC has been in existence, that they've been doing it since the early 90s, that the use case is the perfect ideal for IRC, and that the average modern Web app is less reliable than my last Datsun, I have a hard time finding incredulity at sticking with something that works.
Even beyond that, IRC is text-based. It is not cryptic. An IRC client is a common first software project. About twenty lines of Go gets you a bot. You can make IRC look exactly like Mattermost with a week of hacking in your favorite framework of choice, and then you're not reinventing fanout. Entire products have been built atop IRC.
Even beyond that, guess how many protocols are decades old in just the software development workflow for this product. Pretty tired of "that's old, let's do it better," even though I hate finding myself on this side of defending IRC.
"myIRC" doesn't exist. The name of the protocol is IRC. The name of a popular Windows client is mIRC. WikiLeaks called their leak "mIRC logs," which is where this trope came from.
The United States military (not just the Army) uses Internet Relay Chat for a whole lot of C2. It runs on a network, both IRC and IP, dedicated to the purpose. Given how long IRC has been in existence, that they've been doing it since the early 90s, that the use case is the perfect ideal for IRC, and that the average modern Web app is less reliable than my last Datsun, I have a hard time finding incredulity at sticking with something that works.
Even beyond that, IRC is text-based. It is not cryptic. An IRC client is a common first software project. About twenty lines of Go gets you a bot. You can make IRC look exactly like Mattermost with a week of hacking in your favorite framework of choice, and then you're not reinventing fanout. Entire products have been built atop IRC.
Even beyond that, guess how many protocols are decades old in just the software development workflow for this product. Pretty tired of "that's old, let's do it better," even though I hate finding myself on this side of defending IRC.
IRC federates easily, requires minimal resources, and is vastly more efficient when it comes to bandwidth usage. (you'll notice this over satellite links)
plus it works in screen natively
plus it works in screen natively
How many open source slack alternatives before someone writes one that actually utilizes the IRC protocol?
Is there a defensible argument against using IRC?
Is there a defensible argument against using IRC?
There already are a number of IRC client web frontends. The one I'm working on is Glowing Bear -- https://github.com/glowing-bear/glowing-bear . It uses a proper IRC client running on a server (WeeChat in a terminal multiplexer) and connects to that via WebSockets. Minimal reinvention of the wheel, and you can continue using all those nice scripts, triggers, and filters that WeeChat offers. The frontend (Glowing Bear) is completely static and runs 100% in your browser, connecting to your server directly.
I really don't get those projects that consist of a designer frontend and a terrible half-baked IRC client in nodejs.
I really don't get those projects that consist of a designer frontend and a terrible half-baked IRC client in nodejs.
Designer front ends matter. You have no screenshots, which is going to severely limit adoption. If the design is average or subpar, it will limit adoption.
Also, integrations with third party services matter. Everyone seems to ignore this, but it's critical.
Also, integrations with third party services matter. Everyone seems to ignore this, but it's critical.
Uhm, there is a screenshot in the README, both for mobile and a desktop browser. Maybe we could move it up a bit more. As for the design, sure, you're right that it matters. We try to keep it as clean and intuitive as possible, but none of the core devs is a designer, so we just do it as best as we can. Ideas for improvement (or even pull requests) are always greatly appreciated!
For third party services, Glowing Bear has a number of plugins that embed various content right in the conversation (images, youtube, spotify, etc). Not sure if that's what you're referring to.
For third party services, Glowing Bear has a number of plugins that embed various content right in the conversation (images, youtube, spotify, etc). Not sure if that's what you're referring to.
The uhm is unnecessary; I don't see any screenshots on the GitHub page, linked or otherwise. The page linked from the website is https://github.com/mattermost/platform.
For third-party services, I'm talking about things that matter for getting work done. For example, issue trackers like JIRA.
For third-party services, I'm talking about things that matter for getting work done. For example, issue trackers like JIRA.
The IRC protocol isn't pretty, and there are plenty of incompatible server implementations, but if you're controlling both the server end and the client end it's certainly where I'd start. My first thought when I saw Slack was "someone did a pretty web irc client finally, cool" (I have no idea if they use irc internally? but it seemed such a direct match)
The IRC protocol might not be pretty, but what protocol is? HTTP? AMQP? XMPP? Protocols are not meant to be pretty, just efficient and robust enough to support the desired feature set. It's a shame that none of Slack, Hipchat, now Mattermost support IRC. They're all just IRC clones, drawing on the same ideas, just giving you a crappy (but pretty!) web interface.
Slack "supports" IRC in that you can allow IRC connections, and then people can connect to your Slack instance via IRC. This might also be the case for some of the alternatives.
And it's a pain in the neck! It means that some of the participants in the channel are not able to read what's happened while they were away. Some of them get encoding errors. The IRC people do not get the same graphical elements as everybody else. They can't use custom /-commands.
In conclusion, in order to communicate the most effectively, you have to know who's on IRC and think about the differences in user experience for these people versus everybody else.
IRC has weaknesses (namely lack of centralized logging and unspecified text encoding) and fixing these weaknesses means forgoing support for existing IRC clients.
And it's a pain in the neck! It means that some of the participants in the channel are not able to read what's happened while they were away. Some of them get encoding errors. The IRC people do not get the same graphical elements as everybody else. They can't use custom /-commands.
In conclusion, in order to communicate the most effectively, you have to know who's on IRC and think about the differences in user experience for these people versus everybody else.
IRC has weaknesses (namely lack of centralized logging and unspecified text encoding) and fixing these weaknesses means forgoing support for existing IRC clients.
> And it's a pain in the neck! It means that some of the participants in the channel are not able to read what's happened while they were away. Some of them get encoding errors.
Everyone I've ever worked with who uses IRC has a client or bouncer running somewhere that never disconnects and assumes UTF-8, so neither of these are realistic problems.
Everyone I've ever worked with who uses IRC has a client or bouncer running somewhere that never disconnects and assumes UTF-8, so neither of these are realistic problems.
>centralized logging
A logging program is just another IRC client. Problem solved.
A logging program is just another IRC client. Problem solved.
I also assumed Mattermost supported IRC, without even checking. It's a bit disappointing that it doesn't, but I wonder how easy it'd be to add support for IRC in Mattermost, given that we have the source code?
This is my biggest problem with Slack. It's a cool product that could have been built over IRC. But no, they had to create their own walled garden.
Whilst I take your point, worth noting that Slack does offer an IRC gateway to allow for use via an IRC client. Not quite the same thing as basing everything on IRC, but better than nothing?
Yes, but Slack is slick, plaid, and even gorgeous.
Seriously, these days it seems most software like this is judged purely on its external styling and aesthetic beauty. You're right, Slack has no new features over IRC or any other decent chat clients in the past. But read any article that praises slack and if the slick UI (or whatever adjective is in style these days) isn't mentioned up front and center, I'd be surprised.
Of course the UI's 'slickness' and 'modernity' would be top discussion points for people writing such articles as they're usually not technical enough to argue the merits of tabs vs. spaces or braces vs. non-braces which the creators of such software usually argue about to the detriment of real issues.
Seriously, these days it seems most software like this is judged purely on its external styling and aesthetic beauty. You're right, Slack has no new features over IRC or any other decent chat clients in the past. But read any article that praises slack and if the slick UI (or whatever adjective is in style these days) isn't mentioned up front and center, I'd be surprised.
Of course the UI's 'slickness' and 'modernity' would be top discussion points for people writing such articles as they're usually not technical enough to argue the merits of tabs vs. spaces or braces vs. non-braces which the creators of such software usually argue about to the detriment of real issues.
Can you recommend your favorite protocol OR app for a small dev company where we share files and want to keep a centralized area where team members can chat, using various apps (or web interfaces)? The more robust the better, doesnt have to look amazing!
Here's the code: https://github.com/mattermost/platform
From the look of the screenshots ( http://www.mattermost.org/70-2/ ), I'd say there are some copyright concerns with the styles. This isn't a Slack alternative, it's a Slack clone. That's very problematic from a copyright stance. Why not create your own design style?
Gogs had (has?) this same issue: https://github.com/gogits/gogs/issues/1069
From the look of the screenshots ( http://www.mattermost.org/70-2/ ), I'd say there are some copyright concerns with the styles. This isn't a Slack alternative, it's a Slack clone. That's very problematic from a copyright stance. Why not create your own design style?
Gogs had (has?) this same issue: https://github.com/gogits/gogs/issues/1069
> That's very problematic from a copyright stance
why? they didn't copy slack (i assume) - it just looks similar. Slack doesn't (and shouldn't be allowed) own a look and feel, as long as the implementation of it is cleanroom.
why? they didn't copy slack (i assume) - it just looks similar. Slack doesn't (and shouldn't be allowed) own a look and feel, as long as the implementation of it is cleanroom.
https://en.wikipedia.org/wiki/Trade_dress#United_States
I have no idea if Slack could actually win a case, but in the US (where both companies appear to be headquartered) they do have some rights to look and feel as part of trademark law.
I have no idea if Slack could actually win a case, but in the US (where both companies appear to be headquartered) they do have some rights to look and feel as part of trademark law.
Interesting. There's potential for that as a basis for a civil suit, but i really doubt that the open source alternative could really be argued as trying to misrepresent or cause confusion as to the origin of the product. It'd be a hard case.
[deleted]
I think you misunderstand copyright. You can't copyright a style, only a specific implementation thereof. Unless you're accusing Mattermost of copying code directly from Slack (which you wouldn't be able to tell from a picture), there is no copyright violation.
Mattermost team here,
There's been a number of questions of what's coming from Mattermost, and how we design things. I wanted to share some raw, unpolished work we have of what's coming up.
It's a feature called "App Center" that we're working on to support 3rd party applications.
It's just a Google Doc of our early design that we're sharing on Hacker News to get feedback: https://docs.google.com/document/d/1s6vrticxgz9PsxePQ-dFrsKp...
Would you find this interface interesting for building 3rd party apps?
What do you like about the design?
What do you wish we changed?
There's a couple 1st party Apps we'd start with, like an Admin Console and a Custom Web App. We're thinking there could be a marketplace for 3rd party workflow apps.
Example: create an "Expense Report" app where a user can upload the photo of a receipt from lunch from their phone and type "#expense #meals" and have a 3rd party app create a labeled expense report that would be viewable in App Center.
Would love to hear thoughts from the community. This is an early idea, it's just a Google Doc right now. Your input would help shape it.
There's been a number of questions of what's coming from Mattermost, and how we design things. I wanted to share some raw, unpolished work we have of what's coming up.
It's a feature called "App Center" that we're working on to support 3rd party applications.
It's just a Google Doc of our early design that we're sharing on Hacker News to get feedback: https://docs.google.com/document/d/1s6vrticxgz9PsxePQ-dFrsKp...
Would you find this interface interesting for building 3rd party apps?
What do you like about the design?
What do you wish we changed?
There's a couple 1st party Apps we'd start with, like an Admin Console and a Custom Web App. We're thinking there could be a marketplace for 3rd party workflow apps.
Example: create an "Expense Report" app where a user can upload the photo of a receipt from lunch from their phone and type "#expense #meals" and have a 3rd party app create a labeled expense report that would be viewable in App Center.
Would love to hear thoughts from the community. This is an early idea, it's just a Google Doc right now. Your input would help shape it.
this is how you earn revenue as an OSS platform company (once you get it in the hands of everyone aka build a network)
One thing I really like and appreciate is that there's a dockerfile right in the root of the project, which makes spinning up a container a relatively nice experience... haven't run it or looked into the code though... that just struck out at me...
Looking at the dockerfile, it seems pretty big, and it also strikes me slightly that they have dependencies on node, ruby and go, along with mysql and redis. The UI appears to be react based.. not sure what's running in ruby.
Looking at the dockerfile, it seems pretty big, and it also strikes me slightly that they have dependencies on node, ruby and go, along with mysql and redis. The UI appears to be react based.. not sure what's running in ruby.
I think it's nice that they support Docker, but I was disappointed that their entire installation instructions were "install docker then run our image". I had to read the dockerfile and the "start" script to find out what the actual dependencies and setup steps are.
https://github.com/mattermost/platform/blob/master/Dockerfil...
https://github.com/mattermost/platform/blob/master/docker/do...
Surely even docker users don't want to run this app, mysql, postfix, redis, react, and compass all in the same container?
https://github.com/mattermost/platform/blob/master/Dockerfil...
https://github.com/mattermost/platform/blob/master/docker/do...
Surely even docker users don't want to run this app, mysql, postfix, redis, react, and compass all in the same container?
I agree that a dockerfile isn't perfect, but it's not that bad either as a machine readable install guide that doesn't fall out of date as easily as documentation written for human consumption.
I definitely appreciate projects having Dockerfiles included, but yeah, that's not a good one. They should simply include instructions about how to link it to MySQL/Redis, or use something like docker-compose.
The way it's done now makes it inherently unscalable. Also, there are so many steps that it makes pushing an image to a Docker repository a massive pain.
The way it's done now makes it inherently unscalable. Also, there are so many steps that it makes pushing an image to a Docker repository a massive pain.
+1 for a Docker Compose file
Looks like it's only being used for their scss files.
Also, there is http://getkaiwa.com/, with roughly the same features, open protocol and a built-in LDAP. Hubot integration is also possible.
Nice project but the documentation is a bit terse (yet). We like https://github.com/sdelements/lets-chat atm.
Things that would be essential for me to use it in a company are
- LDAP or OAUTH integration - Hubot integration
I'm not sure Zapier integration cuts it for use cases where I want a self hosted solution.
Things that would be essential for me to use it in a company are
- LDAP or OAUTH integration - Hubot integration
I'm not sure Zapier integration cuts it for use cases where I want a self hosted solution.
What a horribly uncreative rip off. That may sound harsh but I'm a bit floored that this is getting so much attention...but YC right?
Reproducing functionality and growing an idea is fine. It's the blatant disregard to UX and UI where this company has literally pixel for pixel ripped off slack.
Reproducing functionality and growing an idea is fine. It's the blatant disregard to UX and UI where this company has literally pixel for pixel ripped off slack.
Mattermost looks to me like it departs from Slack UI more than some of the other clones I've seen (Rocket Chat, for example).
> It's the blatant disregard to UX and UI where this company has literally pixel for pixel ripped off slack.
I'm finding it hard to parse this sentence. Are you saying ripping off Slack is the blatant disregard, or are you saying Slack pioneered a blatant disregard for UX and UI?
I'm finding it hard to parse this sentence. Are you saying ripping off Slack is the blatant disregard, or are you saying Slack pioneered a blatant disregard for UX and UI?
Sorry about that.
What I meant was that Mattermost is blatantly disregarding their UI/UX by just ripping off Slack. If design was that easy we'd all have the same looking/feeling/functioning product.
What I meant was that Mattermost is blatantly disregarding their UI/UX by just ripping off Slack. If design was that easy we'd all have the same looking/feeling/functioning product.
Mattermost team here. Thank you!! This feedback is awesome. Working on some replies...
Why don't you work on an interface that isn't a nearly exact copy of Slack's before you work on some replies. Copying their functionality is one thing but copying their look and feel is not only pathetic, but against U.S. intellectual property laws. You guys made the equivalent of a Chinese knock-off product. And why not focus on your startup instead of working on cloning other team's hard work?
Once a month an “insert something tech-related here” company releases an open source slack clone.
While I am grateful to all you guys, how much free time do you have to work on these clones instead of your main product?
I've tried so far let's chat and rocketchat and I liked them. I will give a spin to mattermost and I am sure I will like it too. I think the one that matures first, will be a big hit because we need a slack clone —as evidently shown. But also as with any other open source / free software project it will need commitment.
While I am grateful to all you guys, how much free time do you have to work on these clones instead of your main product?
I've tried so far let's chat and rocketchat and I liked them. I will give a spin to mattermost and I am sure I will like it too. I think the one that matures first, will be a big hit because we need a slack clone —as evidently shown. But also as with any other open source / free software project it will need commitment.
Before you disparagingly call it a "clone" and "not their main project", consider that free products often go on to crush their expensive first-to-market predecessors.
The strategy of first seeking to monopolize the user-base, and then afterward heavily monetizing it is a very well proven long term strategy by now. The overnight success of Slack and some other SAAS companies may give some people the impression that this strategy is suddenly irrelevant. It may not be.
The strategy of first seeking to monopolize the user-base, and then afterward heavily monetizing it is a very well proven long term strategy by now. The overnight success of Slack and some other SAAS companies may give some people the impression that this strategy is suddenly irrelevant. It may not be.
[deleted]
Let's Chat is actually three years old :P
That's all good, but the differentiating factor of Slack over Hipchat & the like is how well it integrates with everything your team is likely to use. It works seamlessly with Github, Trello and IRC.
I don't mean to devalue this product at all, but This is not a viable Slack alternative, it's a generic (and good looking) communication tool. This said, I commend the open source approach, it could probably help the product evolve towards something much better and integrated.
I don't mean to devalue this product at all, but This is not a viable Slack alternative, it's a generic (and good looking) communication tool. This said, I commend the open source approach, it could probably help the product evolve towards something much better and integrated.
You know what else is a great open-source on-premises Slack alternative? Most IRCds.
I've run numerous IRCd's for decades. They are completely stable and scale to 10's of thousands of users per VM. I can't even remember the last time I had one crash. There are already tons of integrations for IRC. It is just difficult to get people to understand the simplistic beauty of IRC. People like "shiny", as mobile phone addictions have proven. There are not many great web front ends for IRC that are secure at the same time as being shiny.
There are many slack alternatives out already, as volent has pointed out. What I'd like to see is one that is based on Tox technology.
Having a decentralised network would be much better as it would remove all costs of self-hosting.
Having a decentralised network would be much better as it would remove all costs of self-hosting.
It is more oriented towards real time and spontaneous conversations, but my Firestr project is a p2p chat/app platform. I am working on the idea of more persistent conversations. Check it out, it is still alpha but works well. I am always open for help to make it more awesome too.
http://firestr.com https://github.com/mempko/firestr
http://firestr.com https://github.com/mempko/firestr
Hos does your network work? Is it compleatly distributed, like Tox or does it rely on nodes?
Such self-hosted services might help us a lot, as Slack is currently blocked in China already. I think the two main reasons are that the Chinese government is unable to inspect the data at will, and also they fear sensitive data being leaked to the US government easily, which is actually quite legit. No interest in politics nonsense and having full control over your own sensitive data is probably the best possible thing to do.
I tried to spin up the docker container locally and it worked until it had to send me a mail for registration.
Looking at the README it says that it does not work if my ISP is blocking port 25, which I don't think it is.
But anyway I created a droplet on digitalocean and ran the container there, but "MySQL init process failed."
I would love to try this project, or at least try a demo deployment somewhere :)
Looking at the README it says that it does not work if my ISP is blocking port 25, which I don't think it is.
But anyway I created a droplet on digitalocean and ran the container there, but "MySQL init process failed."
I would love to try this project, or at least try a demo deployment somewhere :)
Me too, mail didn't arrive. Not possible to continue.
Cool :). It would have been nice to see some more screenshots or product videos in order to get a feel for it.
Help: anyone able to get it going on Mac with Kitematic?
Does it set up mail server that can get email to my Gmail account? I signed up but didn't get an email. Are emails dumped somewhere or possible to lookup whatever I need to get started?
Does it set up mail server that can get email to my Gmail account? I signed up but didn't get an email. Are emails dumped somewhere or possible to lookup whatever I need to get started?
Unlike Slack, Mattermost is open source...
Teams suffer when SaaS companies lose focus. Since it’s open source,
Mattermost can endure through its community. If quality declines,
anyone can fork the code and take stewardship.
(a) Mattermost is built by a video game company, so there is no focus to start with.
(b) Moving from a SaaS product to a self-hosted open source component runs against the process of commoditisation so is ultimately only ever going to be of niche value. After all, why spend scarce and expensive engineering time setting up, maintaining, and potentially having to fork a product, when you could just pay $however-much/month and not have to worry about it.
The problem of SaaS is having your company data stored by someone you have to trust... So I reckon it depends on your use case: if I'm a small company who doesn't want to bother running/maintaining the service then I'm more than happy to hand it over to someone else and trust them. If I don't want to trust anyone with my data I'd rather have something simple to deploy and run myself.
The same way that having a closed client prevents you from customising it to fit your needs but can be helpful if you had no intention to do so in the first place.
The same way that having a closed client prevents you from customising it to fit your needs but can be helpful if you had no intention to do so in the first place.
Yeah, there'll always be companies like that but as more and more large orgs, government departments, etc. migrate all their email over to Gmail, I'm starting to consider that as a niche. Those orgs are also disproportionately likely to want to build their own thing because they have a hope of making the economics of scale add up.
True for big corps, although it's quite strange given they're usually the most paranoid ones on security.
But I was more thinking about techie SMBs to whom running a chat/collaboration server is not scary, better in terms of flexibility and cheaper than paying someone to handle it.
But I was more thinking about techie SMBs to whom running a chat/collaboration server is not scary, better in terms of flexibility and cheaper than paying someone to handle it.
There are standards for E-Mail though. So you can move your mail around different providers.
With your chat system it's a lot harder. You can't move your yammer content into slack easily.
With your chat system it's a lot harder. You can't move your yammer content into slack easily.
Is XMPP a standard? I know that everyone just ignores it.
Yep, and Slack supports it, along with IRC.
Cool I guess that one can just transfer easily between vendors then?
Not sure if XMPP covers that, I'm guessing not, but you can export your message history as a dump of JSON files.
It is IETF standard.
Funny you say that, given that the company that built Slack (originally named Tiny Speck) was also a video game company initially. :)
Anonymous downvoters: please build up some courage and actually contribute. I don't bite.
Will there be plugin support so teams can share their add-ons?
Agreed, without a list of the features, or something to show what useability is like (does it support markdown? code highlighting? e.t.c.) it's tough to evaluate it.
Kudos to them for open sourcing it. It does look nice in the small pictures they have of it.
Kudos to them for open sourcing it. It does look nice in the small pictures they have of it.
Does it have email notifications? That's a killer feature missing from most Slack replacements.
Awesome to see more companies questioning Slack, and developing their own solutions!
So, can it be used as an improvement over XMPP? A new IETF standard may be?
Why is there no package? I have to use docker? Why? Why? Why?
Are you planning to open source you android client as well?
Some of the comments here are... aggressive.
Better to have slack-compatible APIs.
[deleted]
can i run it on Linux?
It's available as a Docker container, so yes, it can run on Linux (with or without Docker).
Having a look around the code it's a web based front end (using react) with an api written in Go behind the scenes. From that it sounds like you should be able to run it in Linux (but I haven't installed it myself, just had a peak at the src).
no ldap?
Don't want to troll you guys here, but if you're a video game company why are you spending so much time building a Slack clone?
I was expecting some short of explanation in your blog post like "we did this because this serves as a core piece of our company for X reason and Slack didn't fit our use case for Y reason".