With this attitude of the XMPP Foundation, I doubt XMPP have any future. Better question would be to ask what should be improved in XMPP so that they could implement that properly.
Why? Facebook, google, slack are not using XMPP internally for chat products, because of technical reasons. They dropped XMPP gateway for mix of technical and strategic reasons. Instead of trying to be a warrior for technical correctness, XMPP foundation should rather seek feedback and try to make sure that developers integrating with XMPP will do everything correctly as easy as possible. Otherwise, more and more projects would be dropping XMPP support.
Facebook and Google? They use IRC internally for technical reasons. IRC doesn't fall over. Googlers internally revolted when they were told to use Hangouts internally.
XMPP works great and I've used it at several employers. There's no technical reasons to avoid it; it really is all about lock-in and corporate planning.
I've watched Ralph struggle for years against corporate asshats. It's a real tragedy that all these companies don't participate in open standards. We shouldn't have ever expected good things from Slack.
> Facebook and Google? They use IRC internally for technical reasons. IRC doesn't fall over. Googlers internally revolted when they were told to use Hangouts internally.
I was talking about implementation of Facebook messenger, or Google hangout (which does not use XMPP), not what is used internally for communication.
Also, at Facebook, messenger is most used product internally. IRC is still used, but not that much (depends on org, infra devs use IRC more than product devs). But IRC is still essential, in case of emergencies (where you don't want to use your own product, as it may be down).
Let me first turn this around. I actually personally tried to interact with the Slack team on how they implemented their XMPP gateway, early on. I pointed out how a relatively small missing protocol feature (server-side group chat bookmarking) was severely impacting the usability of the gateway, as it caused caused you to have to explicitly join the group chat room representing a Slack channel on every client (re)connect. In fact they violated protocol in case a client requested the list of bookmarks, causing clients to hang while connecting. It took them a year to start responding, and the problem was not fixed.
Additionally I had pointed that their statements on XMPP security were factually wrong. No useful response or changes were made.
That all said, I really like a bunch of things about Slack and have repeatedly pointed out in discussions in the XMPP community that there is a lot to be learned from Slack in terms of features (and how they work technically), UI consistency, and usability. As JC points out, this is surprisingly hard to achieve in open source projects. Even harder to pull off for a very diverse community around a set of protocols, rather than a single software product.
There are also things in Slack that I think would be a lot better if they were modelled after recent protocol proposals in XMPP. For example we are working on something called MIX, an evolution on group chat, based on Publish-Subscribe. This allows for orthogonal streams of information bound to a channel, besides just chat and presence, like merge request notifications, Twitter mentions, etc. that could be displayed in a side-bar or ticker, instead of (annoyingly) interleaved with chat messages.
I would have welcomed Slack interacting with the community, but they didn't.
I don't know the numbers, but if there's not a lot of users/companies using these alternative protocols, it makes sense not to support them. I'd do the same thing.
The Facebook/Twitter analogy is flawed, because those are ad-supported businesses, so the company has a strong financial interest in having users on its own/primary platform, where it can deliver ads. I think that's not the case with Slack (?). But even there, I think the incentive to not support N protocols is not to get the +0.1% revenue from IRC/XMPP users, it's velocity/simplicity in product development, which is worth more money in the long term.
Disclaimer: I worked for FB previously, on Workplace, which is a direct competitor to Slack.
When you already have too many channels, and then they give you the ability to have too many threads.
I feel like they do a worse job at the supposed value add of being able to archive and later refer to a topic of conversation than channels simply because they are so light weight and proliferate so many of them, potentially.
Plus it's really jarring to be pulled into a bunch of threads.
I think the too-many-channels problem is a symptom of the excessive walled gardening.
Slack segregates by interests and social group, and bundles that with strict gatekeeping. There is no way for people to remix that to suit their own preferences. You can only fragment existing communities more.
I would love a slack multiclient where I can put channels I care about side by side, regardless of origin, and keep the rest out of sight. Instead now everyone has their own #random and #offtopic and so on. Cruising between Slacks and Discords is like navigating a hall of mirrors. If there is disagreement, the only solution is complete schism.
Slack's use as a "community" chatbox is a mangling of its original intent to be used by teams. That's where your pain points are coming from, and some of my own (no /ignore feature, for instance).
I have some of the same issues, but I'm not part of any community slacks. I run my own consulting company, and as such, I've been invited to most of my client's slacks. So I've currently got 37 Slack workspaces going. But most of the time, I'm only concerned with the specific project channel that I'm working on for a client, and I might only be active in 2-3 projects at a time. So I'd love, like OP, to be able to just have those 3 channels front and center.
Yeah, I think this article is needlessly paranoid. I've seen no evidence that their protocol connectors pose any threat to their main business. Like you, I believe that the real problem is development velocity.
As much as I'd like to live in a world where open protocols and federated services evolve as quickly and turn out as well as proprietary solutions, that's apparently not the world I'm living in. Email, as much as I love it, is basically stagnant. IRC existed long before Slack, and if it had been truly successful, Slack would never have existed because there would not have been a market niche. And having recently written a bunch of XMPP code to talk to my vacuum [1], I was entirely underwhelmed. Whereas Slack is a product I use daily because it just works, and works well.
Lockin could mean they use the service, or stronger, they use the service on the official UI (which may have ads). I think for Slack, the first type of lockin is enough (a paying user is a paying user, whether they use IRC or slack.com), whereas for FB the second type of lockin is better because only that can be monetized.
It's better than Slack in terms of usability, performance and UI (subjective), but lacks some integrations that Slack has. Search engine is quite poor (not that Slack is any better, it's shit too).
I'm running the reference Matrix server (Synapse) on my home computer, and I'm using the Riot.im client. I mainly use it to communicate with a group of three friends. They are using Android, and I'm using an iPhone.
It seems to work about as well as any other messaging app, which is impressive if you ask me, considering it's completely open and self-hosted.
> Slack's business model is to record everything said in a workspace and then to sell you access to their record of your conversations.
Whilst this is partially true, One of the key features enterprises need and that Slack supplies is the ability to fully export messages for transfer and compliance purposes.
One of the main differentiators between paid and unpaid slack is message retention. To my knowledge, I don't think the XMPP and IRC were used by anyone to overcome this limit but I'm pretty sure it's been done using their API.
They haven't shut of usage of their API for this purpose so I'm pretty sure that lost sales is the motivation behind this change.
The OP talks about the relevant ways Slack can implement features into their XMPP and IRC endpoints to allow new features. But this probably generates a lot of technical debt for a feature that isn't used by many people. (Also, anecdotally, I've found very few XMPP clients that actually support any of the proposed extensions).
My biggest issue with Slack is that on the free plan they store everything forever, but only allow you to access the last 10,000 messages.
I'm fine with limits, but the users should be free to delete messages beyond the limit. It's my data that I entered in and they are preenting me from deleting it which is a pretty nasty thing to do.
I suspect this will all change in May when the GDPR comes into play. The policy is clearly not compliant. They will likely either need to allow for deletion, or give users access to the data (even on free accounts).
Existing EU data protection law since the mid 90s gives people the right to get a copy of their personal data, with big players, like Facebook, supporting it for years.
I don't know if Slack has any offices or entity in the EU, but you could try making an access request today./
> One of the main differentiators between paid and unpaid slack is message retention. To my knowledge, I don't think the XMPP and IRC were used by anyone to overcome this limit but I'm pretty sure it's been done using their API.
If I understand you correctly, you're saying that you don't know about any message retention facilities for IRC. irclogger and logbot do that.
The author I think is confused about the meaning of Slack's "emoji reactions". They are "badges" that can be applied to messages by any one who is in the channel the message was sent. Discord also has this feature.
At any rate, that doesn't change the fact that it probably could have been implemented in XMPP.
As one of /those/ people still using IRC, I would personally have been totally fine continuing to use the IRC gateway without these features.
I agree, the author complains about something they actually do not understand. I'm sure many people will agree with the author, I'm not sure I do. If Slack changes something or does something that I don't agree with, I will find another solution. If it changes in a way that affects the workplace, we will find another solution. This is why other similar systems exist like Mattermost.
EDIT> Thanks for the downvote! Always fun when disagreeing with the echo chamber causes a loss in Internet points.
My company switched to a free slack account a couple years ago, from our own IRC server. The primary reason for the change was to get something a bit richer in abilities, and emoji reactions is something we make extensive use of. Just saying there are people out there that find these sorts of "XMPP breaking" features not only useful, but mission critical.
Would have been useful if their announcement included some of their data for reaching the conclusion, like "95% of channels use emoji reactions in more than 5% of their messages". The announcement, as it was, didn't read very well to me.
While that use case is certainly an example of a convenience, I don’t think it passes the “mission critical” bar.
I can’t think of any way that emoji reactions would be mission critical unless they are part of an API that can be used for automated execution of tasks. But maybe that sort of thing does exist?
It is a perfectly adequate paper trail. It's much easier to check in a postmortem than shouting something across the desk. Like code review, because you know your approval will be recorded irrevocably, you just think it through that little bit extra before approving.
This is what I don't get; for someone wanting to use an irc client ":thumbs-up:" is as least as good as the actual graphic. Nothing is lost. And that goes for all the built-in emojis in slack.
Now if it was :4677: it'd be a different story - without some support it'd be hard to understand the constant identifiers.
I have to admit, this is the first time in my life I've ever read that someone (a company, no less) switched from one software product to another because the one they switched to had emojis. I somehow feel my life is more complete, like I checked something off my bucket list. Thanks!
> One of the sad things that has come out of Slack's meteoric rise to success, has been how many free and open source projects have jumped over to using it (after previously using IRC or XMPP). In so doing, they have closed off their discussions from search engines and they prevent people from accessing their past archives.
Additionally the traditional mailing lists are full of "please can I have an invite to the Slack workspace" spam
It's not even that discussions have been lost from search engines, actual slack users are loosing massive amounts of history. If you a free/OSS project then you likely have little budget so you're stuck using hte free tier of Slack, which means users can only see the last 10,000 messages. We're loosing vast swathes of our history/discussion/media.
The history isn't searchable, but the owners of the Slack can export the complete public history at any time. Here is an export that I did when we moved Hyperledger to Rocket.Chat: https://github.com/hyperledger/slack-archive
So would there be a use-case for a combined bot+app that you can connect some storage to (S3, FTP) which archives all channel message history in a searchable form? It could make it visible to search engines, searchable by humans, linkable to people outside of slack, and shouldn't take up very much storage space.
Should be quite trivial to build also, and cheap enough to run as a bit of charity if projects pay for their own storage.
Local client logging doesn't solve all problems (though yes, i still want to be able to grep text files if I choose).
The two I regularly encounter (which shared storage fixes) is either moving to a different device (or trying to remember which ones have which bits of history on) and also integrating new team members.
The latter is especially important if you're doing anything technical/support related; if you've had 2 days of discussions and want to add someone else in, they need the history, not for you to try and cherry pick the important bits of the last few hours to then fail to get them upto speed.
This is the main reason why my team switched to use self-hosted Mattermost. Unlimited message history is important for us, but not worth what Slack would cost when something like Mattermost is available. If you're a tech team with people who know Linux, I don't understand why you would choose Slack over something like Mattermost. If you're a small business without a tech team, more understandable.
Honestly, it was so smooth. Deleting old unnecessary channels seems impossible, but whatever. Have all of our chat history migrated over, no complaints. One team member missed the old Slack colour scheme, but he found a Slack skin for Mattermost that makes it look the same for him.
Have not. We don't do much screen sharing among our own team, and external screen sharing is done using other tools. Interested in other people's opinions about it though.
If you are asking about Slack's Zoom plugin, I used it at a previous job, and it's pretty good. (We were a small team in Sunnyvale, CA, the bulk of the team was in Phoenix, some in Seattle)
I meant Mattermost - is the Slack one representative, i.e. it's the same client software behind a thin shim layer? Does it work as well as Hangout in terms of voice / image quality and stability? Can people click the screen and the presenter sees where they clicked?
Some nice folks I know recently started http://relay-chat.com/ which is a hosted version of MatterMost. It allows both private instances as well as creating a team at http://open.relay-chat.com
I am more concerned about Mattermost long term future than Slack. If/when slack gets obsoloted and abandonned for the next big thing then what of Mattermost ? Will it have enough developpers's mindshare to ensure its existence considering if slack is gone then there's no need to provide an alternative ?
I suppose it'd be better to build a slack clone based on xmpp.
I'm not so concerned. I think the only thing that would kill Slack is financial factors (financing if it turns out people don't want to pay for it anymore) or bureaucratic factors (if it gets acquired and then mired in corporate stupidity). I think Slack did the favour of proving to the world that people wanted something more than IRC or Skype.
If Slack dies for any of the above reasons, that won't cause people's need for a solution to disappear. I imagine Mattermost would survive just fine. If Mattermost dies, it will be because something came along that's better, similar to how I started out with ICQ, then jumped to MSN Messenger, and now I'm on Whatsapp, WeChat, Kakao Talk, Slack, and Mattermost. Same for Slack. If Slack dies because of better competition, perhaps we'll shift to that away from Mattermost. Who knows?
Gah, how is it possible that the number of chat clients I use keeps growing?
Mattermost is open and self hosted so if development stops it'll just continue to exist in an unchanging state. If people start communicating in another way, their Mattermost history will still be available and searchable.
If you're a free/OSS project and have set up a non-profit, Slack will upgrade you to unlimited messages for free. I know because I'm in such a slack channel (lichess.org).
That's why I use Discord, the free tier has _unlimited_ history. The client itself is lightweight, and it's an incremental improvement on IRC in many other areas, as you would expect. Still using IRC of course :)
Discord is an Electron app, so while it's not as bad as Slack, it's still hardly what I'd call lightweight, especially in comparison to IRC/XMPP clients.
There's a lot to like in Discord, and it rapidly became the go to client for all my gaming related friends and activities, but it suffers from the same root pitfalls that Slack always has. It will inevitably run out of VC money (or whatever they're spending now) at some point and start wanting to actually turn a profit.
I imagine this problem would be remedied by an acquisition.. or at least masked... Twitch (Amazon) seems a likely candidate, considering it's usage by Twitch users, and also the fact that Amazon doesn't really have skin in the game currently in the chat market (do they?), and could use a product like Discord in their ecosystem.
Some time ago, Twitch bought Curse, probably for the Curse App that already does voice and text chat. Also viewing streams and mod management for a handful of games.
Exactly! As pointed out in the article: "Slack's business model is to record everything said in a workspace and then to sell you access to their record of your conversations."
Slack recognizes, unfortunately before most of it's customers, that the history is one of the most important assets of a company -- it is the shared institutional knowledge, the thousands of hard-won lessons of all the things that can go wrong that are now fixed, and how they were fixed. This institutional knowledge is not only in the heads of the workers, but also in the papers, and many would need, or at least benefit from, a lookup of the details to re-use that knowledge.
This institutional knowledge is a key competitive advantage of almost every company.
This business model of capturing it and rent-seeking on selling it back to them is a devil's bargain.
"Here's this really slick UI for free, only costs a bit later... nevermind that we'll own the soul of your company and you'll need to pay us tribute in perpetuity..."
I believe one of the problems there is an inaccessibility problem. Atleast for the mailing list.
Most mailing list archives lack fulltext search and a modern looking design (I'm not even asking for an SPA or anything JS, just a tiny bit of CSS could make a lot of difference).
It's also not as easy to onboard, integrate and host mailing lists.
Ideally a mailing list could be hosted with a few button clicks, people could join a mailing list like they join newsletters (instead of having to send an email to the mailing list application with some command in it) and people should be able to anonymously send emails.
Plus points if you can, optionally, manage emails like github issues and properly keep track of bug reports.
I'm not a big fan of mailing lists either, for the reasons you describe
What I do dislike though is, as Slack is invite only (the software is designed for "Teams" in workplaces, not public forums) you have to explicitly request access from the admins and this is often via the mailing lists.
The invite-only nature of slack is probably why I never spend any serious amount of time in any slack, though some other factors may play a role too considering I quite enjoy Discord (OSS discords never seem to replace any discussion board, only supplement it, plus discord has unlimited search)
I rarely see a big textbox on the top of the main page of any mailing list archive that says "Fulltext search" (and isn't totally crap). "NNTP Gateway" doesn't sound encouraging in that it is explained and available for the layperson to easily employ as search tool.
I'm actually of the opinion that it would have been better to have a NNTP server to host various newsgroups instead of having various mailing lists. This would have made it much easier to view previous messages posted to the group and would have made it much easier to browse by those who don't participate.
The disadvantage is that it would require one to create an account on another server instead of just using one's existing email account for communication.
As for explaining and availability, I believe the vast majority of people would use search engine to figure out what steps are involved once something like that is mentioned.
Just a heads up. If you suddenly feel that IRC is too feature free or outdated for your needs, have some courtesy and consider a modern, federated and open solution instead.
Also, for those still using IRC, and needing an easy way to get others on it: IrcCloud is an excellent service with a mobile client lightyears beyond any other.
https://gitter.im/ was acquired by GitLab and thus likely to remain for quite a while. Also, it might even suit the needs of such a project better than Slack, as apparently it's aimed more at communities rather than teams, but I'm not sure what that means in practice.
Register matrix.org accounts there. There's a web client, desktop clients and mobile clients (called Riot.im). It's open source and federated. And, there are IRC bridges!
if there was an XMPP based hosted chat application that lets me create private rooms for my company (using google auth), I would migrate in a heartbeat.
however, XMPP mistakes open-ness in the protocol with openness in conversations. Every showcase XMPP product is public, open chat rooms.
its not just at the room level, its at the org level.
the standard practice is that people create rooms in a slack org - and they are guaranteed that they are private to the org. one more step is where i can create private rooms to a few people within the org.
XMPP obviously can support this, but the products built on top of XMPP are too open. The protocol doesnt have an issue - but the people building products on top of XMPP have an inherent distaste for organizational workflows.
No, I'm not. For one, I've never used it. The parent comment was referring to how they provided endpoints for programs connecting through open protocols, and now that they have some sort of critical mass, just dismissing the users of the service that utilize it through those. And my comment supports the viewpoint that we fall in for UX and convenience and low/no cost, then get screwed like this.
Yes, you are. That is a large reason why Slack became popular in the first place. Nobody "fell for" the UX and convenience; those were solid improvements that people took to because they made things better.
I'm not going to play this game of yes you are no I'm not, but even if you're right, then that's not actually the topic of the dicussion: both I and the initial commenter was talking about how they lured people in with UX stuff or solid improvements like you said, and now pulled of this move.
Emoji reactions are a different feature than sending emoji.
Also, the idea that e-mail predates the surveillance aspect of the Web... Well, that was baked in from the beginning, as detailed in Surveillance Valley.
Bait and switch is a bit harsh, I guess most of their users don't use IRC and it's a huge waste of resource and time for them. Even Open Source projects drop support for old tech like debian dropped support for old SPARC architecture in 2015. Of course the difference is that with Open Source anyone can pick up where they left but that's an issue with any proprietary/close source software and it's a risk one takes when going with a solution such as Slack.
They never embraced IRC, they just had a gateway for people still using it. This would be valid if Slack's protocol was based on IRC and they later extended it and made it incompatible with IRC. This is not the case here.
> Slack, like so many others before them, pretend to care about interoperability, opening up just so slightly, so that they can lure in people with the promise of "openness", before eventually closing the gate once they've achieved sufficient size and lock-in.
On spot. People are lured in by hype and forget the long-term consequences. Always chose “open” by design, never by charity.
I'd be interested to know how widely used these gateways are, since the conventional wisdom on HN is so frequently "vote with your wallet/feet/personal data".
As a user, I was very disappointed to see that the gateways must be enabled by the project owner, not by the users themselves. In the end none of the Slack groups I've participated in allowed me to connect via IRC/XMPP.
Slack is an in-company chat product (their slogan is literally “where work happens” [1]) and it was never intended for public groups, which is why all invite automation tools for Slack are third-party. Slack doesn’t want you to use their product as a public chatroom and they try really hard to make that as unattractive as possible.
Given that, “moderation nightmare” is not really a concern for the target audience since if your company needs moderation in its work chat, you have much bigger problems.
No, it's still an assumption - the outcome perhaps is what a person expects will happen, however that doesn't then validate a past assumption - it does validate their past belief/prediction/expectation though.
No it's not. You're conflating "it was terminated" with "it was designed with termination in mind". It's a fact that it was terminated, true, but this doesn't necessarily mean that it was designed with termination in mind. For all we know, it may have been designed with every intention of continuing IRC/XMPP support until yesterday when an executive decision suddenly said otherwise. Now, I don't believe that, but that doesn't matter: the fact that it was terminated is not the fact that it was designed with termination in mind.
I can't answer the broader question, but I did attempt to use the XMPP gateway for a little while. Many features were implemented in ways that made them hard or impossible to follow when viewed via XMPP (threading was a big one), and there were a fair number of bugs. It very much felt like a tacked-on feature as opposed to something they would have expected to be used in a meaningful way.
Doing the reforge course this was something that really stuck out for me. These tech platforms promise the world then slowly cut things out or become inefficient over time to cater for enterprise clients. If you are interested read this https://medium.com/point-nine-news/the-lifecycle-of-lead-gen...
The number of people who used slack because of the XMPP or IRC gateway is probably miniscule. If they accounted for a significant percentages of users, they wouldn't have shut it off.
Well, they did that the moment non-tech people started pushing for slack, and the decisions to adopt this was no longer in the techies hands.
The company I currently work for was very hesitant of adopting it, and they only did the moment our sales people started asking for it. And as a productivity tool it's great, but there is obviously a lock-in.
My major preference for Slack was replacing Skype chats, so there was no loss in terms of open source.
Lots of people complain that it's just a fancy IRC client, but they don't realise how painless it is to get non-tech people to start using it.
But quite clearly there needs to be a fully open sourced alternative.
I think WordPress is a great example of how it should be done. Provide a super simple way to create xxx.slackclone.com in exactly the same number of steps as it takes to create a slack group whilst also providing something that you can download and install yourself.
I think any project would have to be in PHP. Perhaps that sounds stupid but I think again following the WordPress model is a good track. PHP is the most easy way for low-tech people to get their own up and running. It should be as easy as the 5-minute WordPress install to get your own server.
edit: Plus PHP is what Slack is built on and I quite like the irony. The further irony though is that WordPress use Slack now. Perhaps in a similar way that WordPress fought against the React licensing they might replace Slack if there was a good enough clone.
As far as I can tell the aim could be to create as close as possible a clone of slack, ripping off as many features as possible without stepping over a boundary where Slack could try and shut you down.
I agree, no idea why you are downvoted.
At my job the Slack was forced on us by boss, probably because of the hype, we were using Skype before and we still use it because the team was used to Skype, it worked good enough, slack just added for us extra distractions.
I think that even a good alternative appears if the hype is not enough it won't catch, also before Slack we used Hipchat for a short time, same story, it was imposed to the team because of the hype, in the end Slack got a bigger hype I assume.
Their business model is fine for many groups of user. However - open source projects in particular should be thinking about archiving, accessibility, discoverability etc. Slack is a bizarre choice which I can only ascribe to "nice UI and good timing".
I'm personally getting a bit sick of it for another pragmatic reason. It's bloody slow to open, slow to switch accounts and even slow to switch channels.
There is very little "nice" about their UI. UX isn't good (subjective, I know); it's not accessible at all; their "apps" take gigs of RAM and waste CPU, very slow search, not intuitive, etc.
I was able to search years of intensive mailing in both server and local cache in an almost instantaneous fashion in Outlook {2003, 2010 & 2016} for Windows, but Slack can't properly search a year and a half of history without choking. On almost every level, slack is a complete technological failure (where it matters).
I'm really not sure how the two can be separate. In user interface concepts, UI design and UX go hand in hand. As a matter of fact, they do not just for UI but almost everywhere else. Case in point, Apple's glass windows that caused people to hit their heads in them by mistake. Terrible design and terrible UX.
It's going to be open-sourced at some point, just not now.
What I meant is I'm building an alternative client that gives people a lot more freedom. For example, you can use XMPP as your primary messenger, and still communicate with your teammates via Slack.
You can also have access to all your history and a much, much better instant search.
In the future, an IRC/XMPP gateway will be built in as well.
Opening a project early to contributors can end in mixed milestones, and the project may never archieve an "stable" status.
I might not be using the best words, so I'll give examples: Dolphin, the GameCube/Wii emulator did not release it's source code until the program's structure was mature enough to start adding thirth party code without disrupting the project's core codebase.
I will always cheer on someone building something cool, but here's the problem I have: Everyone wants to build an open source alternative, no one wants to make money. What is wrong with making money? Money is great -- it lets you buy clothes, food, shelter, water, and even a night out on the town or two. We need to be able to make money on software again, not just have user data be the product. This is partly to blame on the FOSS zealots. Sure they say it's "just fine" to make money on your software, but they never seemed to offer a method that is based in reality.
Well he didn't say he wasn't going to earn money from the project, just that the client is free. There are many ways to monetize something and the benefits of starting with free is that you get biggest growth and then you can find your "whales" and learn how to profit from them.
I 100% agree with you. I want this product to make money so that I can devote my full time to it.
The basic functionality will always be free without ads and tracking. But there will also be a very affordable ($1-2/mo) premium plan. I haven't yet decided what it's going to have. Most likely an ability to add more than 5 accounts or multiple accounts on the same platform (e.g. 3 Slack profiles).
- I have a paid+OSS app for amateur radio geolocation on Google Play myself. You can download the APK from the homepage or just directly buy it for some bucks.
Don’t price your service so low! Anything below $5/mo gives the perception of having little value to offer. Plus you’re gonna lose a fat percentage to credit card processing.
It doesn't seem like the parent wants to build an open source alternative. I remember reading about it over half a year ago (back then it was supposedly written in Go rather than C if I remember correctly) where there was also promise of open sourcing it.. His website also seems to indicate he now wants to go the route of SublimeText, so the open source promise should probably be interpreted as "I'll release the source code after I abandon the project, whether it takes one or ten years"..
FYI, I have nothing against closed source projects, but every discussion about eul.im seems to include the promise of open sourcing the project, which I'm sure is a great marketing ploy.
Congratulations, we really need leaner IMs and from what I see it looks great!
If it supports some important features like file uploading, pinning and seeing pinned threads, etc. to reach Slack feature parity I'll surely take a shot.
Are you using QT for cross-platform compatibility or some other toolkit?
Well, Qt would still take up that space. It's just that on those platforms it's likely installed elsewhere and used by enough other things that it's closer to the "general userland size" category than it is to any one "specific application size".
Hard to believe this is the same people who once worked in Glitch[0] and I wager that long after Slack is dead and buried, people will probably remember "that one quirky online game" with more fond memories than their productivity and resource-sapping amnesiac-unless-you-pay-up abomination of a product.
- Mentions: Many times I've tried to mention someone but Slack goes and picks the wrong person. If I'm typing `@johnd`, then it should be fairly evident that I'm trying to mention `@johndoe`; don't make me go through that UI when you should have enough info already.
- Buggy snippets: Why do I have to go through a slow UI just to paste some code, when triple-backtick should be enough?
- Triple-backtick: No code highlighting. And just try to copy its content; you'll be surprised when your clipboard looks as if passed through an `s/\n/\n\n/g` filter.
- Scroll up: Scrolling up many pages above causes some weird jumps.
---
Incidentally, the Discord people got all these things right.
IRC is just so good because its flexible to the wish of the tools and type of desktop you use that people should get time to think before use that type of trap for geek.
Off-topic. Every time I hear about XMPP I remember signal's moxie bashing it.
What is currently the mainstream opinion regarding XMPP and good security: is it possible? Is moxie an outlier in saying that it's not possible, or is that the mainstream opinion too?
When Moxie wrote that blog post[1] he was only speaking on behalf of his business interests. Signal is a proof-of-concept application that Open Whisper Systems uses to show off and sell their technology to other chat companies like how they have been doing with WhatsApp[2], Google[3] and Microsoft[4].
He was not really speaking for what was best for the community, you can read the blog post as marketing material.
Why? The blog post was before Matrix.org even had encryption. The Signal project has limited resources, which it focused on the Signal protocol. Matrix builds on this work and invests in federation.
> Signal is a proof-of-concept application that Open Whisper Systems uses to show off and sell their technology to other chat companies like how they have been doing with WhatsApp[2], Google[3] and Microsoft[4].
This is a very uncharitable interpretation. Signal is arguably more secure than the competitors you mentioned, not just a "proof-of-concept".
> He was not really speaking for what was best for the community, you can read the blog post as marketing material.
In the blog post Moxie mentioned usability concerns due to federation, which directly affect users.
> So they have to close everything off, to make sure that people can't extract their conversations out of the silo.
I totally agree with article itself, but this is rather moot point. Slack still provide full history export for free and it's rather easy to self-host said history. IRC and XMPP didn't made it any easier to extract that data.
I aware that export doesn't include private messages, but it's not what Slack used for mostly anyway.
> Slack still provide full history export for free
Wrong. If you want to export messages earlier than the last 10k, Slack will extort you to the tune of $10 per user (even if they aren't active). And that's per fucking month. Does your startup/club/laboratory of 29 people have $290/mo of income to incinerate, when you could just host an AWS IRC server for 1% of that?
Before making comment that you claim is false I went to our team management panel and exported full history for our team since 2016. It's not super active team we have, but it's still 20MB of logs in JSON and 64939 messages according to simple grep:
OP must have little idea or has given little thought to how hard it can be to maintain on-going support for a feature a very, very tiny percentage of customers use.
As far as I know, Slack never pitched as the guys who would rescue IRC out of obscurity and into mainstream. If they did, then you could perhaps fault them for giving up too easily without serious effort.
Everytime someone mentions bait and switch it is always about someone who is not paying for the service/product.
You found a way to not pay for the service, they decided to close it, you are angry that either you have to pay or find alternative.
Love the idea! XMPP was well on its way to dominate until Apple released the iPhone and killed XMPP with the APNS requirement. Here's hoping we can go back to the federated model.
There is some serious work on making federated XMPP work together with APNS.
The iOS client developer needs to run a proxy server that will accept notifications from XMPP servers and wake up the client via APNS (this is required by how APNS authentication works).
The client can connect to any server that supports XEP-0357: Push Notifications [0], and can register the respective push proxy with the XMPP server.
ChatSecure for iOS [1] has implemented this approach, but the client still needs some more polish.
359 comments
[ 2.5 ms ] story [ 320 ms ] threadhttps://twitter.com/ralphm/status/971461404900372480
Why? Facebook, google, slack are not using XMPP internally for chat products, because of technical reasons. They dropped XMPP gateway for mix of technical and strategic reasons. Instead of trying to be a warrior for technical correctness, XMPP foundation should rather seek feedback and try to make sure that developers integrating with XMPP will do everything correctly as easy as possible. Otherwise, more and more projects would be dropping XMPP support.
I like the attitude of telling the truth. Compare to Torvalds.
Care to elaborate?
XMPP works great and I've used it at several employers. There's no technical reasons to avoid it; it really is all about lock-in and corporate planning.
I've watched Ralph struggle for years against corporate asshats. It's a real tragedy that all these companies don't participate in open standards. We shouldn't have ever expected good things from Slack.
I was talking about implementation of Facebook messenger, or Google hangout (which does not use XMPP), not what is used internally for communication.
Also, at Facebook, messenger is most used product internally. IRC is still used, but not that much (depends on org, infra devs use IRC more than product devs). But IRC is still essential, in case of emergencies (where you don't want to use your own product, as it may be down).
Eve Online just abandoned their own in game chat server and replaced it with ejabberd.
Additionally I had pointed that their statements on XMPP security were factually wrong. No useful response or changes were made.
That all said, I really like a bunch of things about Slack and have repeatedly pointed out in discussions in the XMPP community that there is a lot to be learned from Slack in terms of features (and how they work technically), UI consistency, and usability. As JC points out, this is surprisingly hard to achieve in open source projects. Even harder to pull off for a very diverse community around a set of protocols, rather than a single software product.
There are also things in Slack that I think would be a lot better if they were modelled after recent protocol proposals in XMPP. For example we are working on something called MIX, an evolution on group chat, based on Publish-Subscribe. This allows for orthogonal streams of information bound to a channel, besides just chat and presence, like merge request notifications, Twitter mentions, etc. that could be displayed in a side-bar or ticker, instead of (annoyingly) interleaved with chat messages.
I would have welcomed Slack interacting with the community, but they didn't.
The Facebook/Twitter analogy is flawed, because those are ad-supported businesses, so the company has a strong financial interest in having users on its own/primary platform, where it can deliver ads. I think that's not the case with Slack (?). But even there, I think the incentive to not support N protocols is not to get the +0.1% revenue from IRC/XMPP users, it's velocity/simplicity in product development, which is worth more money in the long term.
Disclaimer: I worked for FB previously, on Workplace, which is a direct competitor to Slack.
Disclaimer: I hate threads in slack
When you already have too many channels, and then they give you the ability to have too many threads.
I feel like they do a worse job at the supposed value add of being able to archive and later refer to a topic of conversation than channels simply because they are so light weight and proliferate so many of them, potentially.
Plus it's really jarring to be pulled into a bunch of threads.
Slack segregates by interests and social group, and bundles that with strict gatekeeping. There is no way for people to remix that to suit their own preferences. You can only fragment existing communities more.
I would love a slack multiclient where I can put channels I care about side by side, regardless of origin, and keep the rest out of sight. Instead now everyone has their own #random and #offtopic and so on. Cruising between Slacks and Discords is like navigating a hall of mirrors. If there is disagreement, the only solution is complete schism.
As much as I'd like to live in a world where open protocols and federated services evolve as quickly and turn out as well as proprietary solutions, that's apparently not the world I'm living in. Email, as much as I love it, is basically stagnant. IRC existed long before Slack, and if it had been truly successful, Slack would never have existed because there would not have been a market niche. And having recently written a bunch of XMPP code to talk to my vacuum [1], I was entirely underwhelmed. Whereas Slack is a product I use daily because it just works, and works well.
[1] http://github.com/wpietri/sucks
Gitlab integration?
It seems to work about as well as any other messaging app, which is impressive if you ask me, considering it's completely open and self-hosted.
Whilst this is partially true, One of the key features enterprises need and that Slack supplies is the ability to fully export messages for transfer and compliance purposes.
One of the main differentiators between paid and unpaid slack is message retention. To my knowledge, I don't think the XMPP and IRC were used by anyone to overcome this limit but I'm pretty sure it's been done using their API.
They haven't shut of usage of their API for this purpose so I'm pretty sure that lost sales is the motivation behind this change.
The OP talks about the relevant ways Slack can implement features into their XMPP and IRC endpoints to allow new features. But this probably generates a lot of technical debt for a feature that isn't used by many people. (Also, anecdotally, I've found very few XMPP clients that actually support any of the proposed extensions).
I'm fine with limits, but the users should be free to delete messages beyond the limit. It's my data that I entered in and they are preenting me from deleting it which is a pretty nasty thing to do.
I suspect this will all change in May when the GDPR comes into play. The policy is clearly not compliant. They will likely either need to allow for deletion, or give users access to the data (even on free accounts).
I don't know if Slack has any offices or entity in the EU, but you could try making an access request today./
If I understand you correctly, you're saying that you don't know about any message retention facilities for IRC. irclogger and logbot do that.
At any rate, that doesn't change the fact that it probably could have been implemented in XMPP.
As one of /those/ people still using IRC, I would personally have been totally fine continuing to use the IRC gateway without these features.
EDIT> Thanks for the downvote! Always fun when disagreeing with the echo chamber causes a loss in Internet points.
I've updated the article to clarify.
Would have been useful if their announcement included some of their data for reaching the conclusion, like "95% of channels use emoji reactions in more than 5% of their messages". The announcement, as it was, didn't read very well to me.
Obviously, this could be done differently. But it's easy to do it like this and come to depend on it.
I can’t think of any way that emoji reactions would be mission critical unless they are part of an API that can be used for automated execution of tasks. But maybe that sort of thing does exist?
Now if it was :4677: it'd be a different story - without some support it'd be hard to understand the constant identifiers.
/shrug
Additionally the traditional mailing lists are full of "please can I have an invite to the Slack workspace" spam
I see the hosted version is down, though.
Should be quite trivial to build also, and cheap enough to run as a bit of charity if projects pay for their own storage.
The two I regularly encounter (which shared storage fixes) is either moving to a different device (or trying to remember which ones have which bits of history on) and also integrating new team members.
The latter is especially important if you're doing anything technical/support related; if you've had 2 days of discussions and want to add someone else in, they need the history, not for you to try and cherry pick the important bits of the last few hours to then fail to get them upto speed.
Slack might cut it off, but they gain nothing by doing it.
Any caveats, gotchas or hidden complexities to be aware of?
I suppose it'd be better to build a slack clone based on xmpp.
If Slack dies for any of the above reasons, that won't cause people's need for a solution to disappear. I imagine Mattermost would survive just fine. If Mattermost dies, it will be because something came along that's better, similar to how I started out with ICQ, then jumped to MSN Messenger, and now I'm on Whatsapp, WeChat, Kakao Talk, Slack, and Mattermost. Same for Slack. If Slack dies because of better competition, perhaps we'll shift to that away from Mattermost. Who knows?
Gah, how is it possible that the number of chat clients I use keeps growing?
edit: typo
It turns out that people don't necessarily want lots of records of everything everywhere.
I sure do hope this is sarcasm. Surely you do know this can go away at any time.
The problem with better chat is that it's better, so you spend more time on it.
There's a lot to like in Discord, and it rapidly became the go to client for all my gaming related friends and activities, but it suffers from the same root pitfalls that Slack always has. It will inevitably run out of VC money (or whatever they're spending now) at some point and start wanting to actually turn a profit.
Slack recognizes, unfortunately before most of it's customers, that the history is one of the most important assets of a company -- it is the shared institutional knowledge, the thousands of hard-won lessons of all the things that can go wrong that are now fixed, and how they were fixed. This institutional knowledge is not only in the heads of the workers, but also in the papers, and many would need, or at least benefit from, a lookup of the details to re-use that knowledge.
This institutional knowledge is a key competitive advantage of almost every company.
This business model of capturing it and rent-seeking on selling it back to them is a devil's bargain.
"Here's this really slick UI for free, only costs a bit later... nevermind that we'll own the soul of your company and you'll need to pay us tribute in perpetuity..."
Most mailing list archives lack fulltext search and a modern looking design (I'm not even asking for an SPA or anything JS, just a tiny bit of CSS could make a lot of difference).
It's also not as easy to onboard, integrate and host mailing lists.
Ideally a mailing list could be hosted with a few button clicks, people could join a mailing list like they join newsletters (instead of having to send an email to the mailing list application with some command in it) and people should be able to anonymously send emails.
Plus points if you can, optionally, manage emails like github issues and properly keep track of bug reports.
What I do dislike though is, as Slack is invite only (the software is designed for "Teams" in workplaces, not public forums) you have to explicitly request access from the admins and this is often via the mailing lists.
The disadvantage is that it would require one to create an account on another server instead of just using one's existing email account for communication.
As for explaining and availability, I believe the vast majority of people would use search engine to figure out what steps are involved once something like that is mentioned.
https://riot.im/
https://matrix.org/
Register matrix.org accounts there. There's a web client, desktop clients and mobile clients (called Riot.im). It's open source and federated. And, there are IRC bridges!
https://movim.eu/ is another option (has a fancy web client, android & linux client and of course supports any XMPP client)
You don't have to host your own server.
however, XMPP mistakes open-ness in the protocol with openness in conversations. Every showcase XMPP product is public, open chat rooms.
I intend to release that soon to https://inverse.chat.
Rooms can be made private, members-only and non-searchable. This is standard XMPP behavior.
the standard practice is that people create rooms in a slack org - and they are guaranteed that they are private to the org. one more step is where i can create private rooms to a few people within the org.
XMPP obviously can support this, but the products built on top of XMPP are too open. The protocol doesnt have an issue - but the people building products on top of XMPP have an inherent distaste for organizational workflows.
There are various commercial solutions that offer this.
Long term thinking is so uncommon it's almost frowned upon.
Yes, you are. That is a large reason why Slack became popular in the first place. Nobody "fell for" the UX and convenience; those were solid improvements that people took to because they made things better.
Also, the idea that e-mail predates the surveillance aspect of the Web... Well, that was baked in from the beginning, as detailed in Surveillance Valley.
On spot. People are lured in by hype and forget the long-term consequences. Always chose “open” by design, never by charity.
As they say: Use it or lose it.
Given that, “moderation nightmare” is not really a concern for the target audience since if your company needs moderation in its work chat, you have much bigger problems.
[1] https://slack.com/
It's designed with termination in mind.
The company I currently work for was very hesitant of adopting it, and they only did the moment our sales people started asking for it. And as a productivity tool it's great, but there is obviously a lock-in.
Lots of people complain that it's just a fancy IRC client, but they don't realise how painless it is to get non-tech people to start using it.
But quite clearly there needs to be a fully open sourced alternative.
I think WordPress is a great example of how it should be done. Provide a super simple way to create xxx.slackclone.com in exactly the same number of steps as it takes to create a slack group whilst also providing something that you can download and install yourself.
I think any project would have to be in PHP. Perhaps that sounds stupid but I think again following the WordPress model is a good track. PHP is the most easy way for low-tech people to get their own up and running. It should be as easy as the 5-minute WordPress install to get your own server.
edit: Plus PHP is what Slack is built on and I quite like the irony. The further irony though is that WordPress use Slack now. Perhaps in a similar way that WordPress fought against the React licensing they might replace Slack if there was a good enough clone.
As far as I can tell the aim could be to create as close as possible a clone of slack, ripping off as many features as possible without stepping over a boundary where Slack could try and shut you down.
I think that even a good alternative appears if the hype is not enough it won't catch, also before Slack we used Hipchat for a short time, same story, it was imposed to the team because of the hype, in the end Slack got a bigger hype I assume.
I'm personally getting a bit sick of it for another pragmatic reason. It's bloody slow to open, slow to switch accounts and even slow to switch channels.
I was able to search years of intensive mailing in both server and local cache in an almost instantaneous fashion in Outlook {2003, 2010 & 2016} for Windows, but Slack can't properly search a year and a half of history without choking. On almost every level, slack is a complete technological failure (where it matters).
It doesn't have the 10 000 messages limit, it's very light (~100 KB) and fast:
https://eul.im
I recently started working on it full-time, so I expect a stable release to be out this month.
> You have macOS 10.12.6. The application requires macOS 10.13 or later.
Run it from Terminal for now:
~/Downloads/eul.app/Contents/MacOS/eul
I'll fix this in v0.31.
I'll be following this for sure <3
Wrapping up the Linux GUI bit will only take a couple of days.
By building a closed-source client?
Cool project; it's really impressive and I'd love to use once it gets stable, but don't you think your claim is a bit incompatible with your method?
What I meant is I'm building an alternative client that gives people a lot more freedom. For example, you can use XMPP as your primary messenger, and still communicate with your teammates via Slack.
You can also have access to all your history and a much, much better instant search.
In the future, an IRC/XMPP gateway will be built in as well.
I might not be using the best words, so I'll give examples: Dolphin, the GameCube/Wii emulator did not release it's source code until the program's structure was mature enough to start adding thirth party code without disrupting the project's core codebase.
I 100% agree with you. I want this product to make money so that I can devote my full time to it.
The basic functionality will always be free without ads and tracking. But there will also be a very affordable ($1-2/mo) premium plan. I haven't yet decided what it's going to have. Most likely an ability to add more than 5 accounts or multiple accounts on the same platform (e.g. 3 Slack profiles).
Examples:
- Conversations, the Android XMPP client, is GPL and sold on Google Play: https://play.google.com/store/apps/details?id=eu.siacs.conve... - There is also a paid hosted XMPP service on conversations.im.
- I have a paid+OSS app for amateur radio geolocation on Google Play myself. You can download the APK from the homepage or just directly buy it for some bucks.
- X-Chat, the OSS IRC client has a paid Windows version: http://xchat.org/windows/
You could OSS your app under whatever license you want, and still provide paid builds for any platform you want.
I don't want to charge a lot for a chat client, but these prices are not final. I know that charging too little is a mistake.
FYI, I have nothing against closed source projects, but every discussion about eul.im seems to include the promise of open sourcing the project, which I'm sure is a great marketing ploy.
If it supports some important features like file uploading, pinning and seeing pinned threads, etc. to reach Slack feature parity I'll surely take a shot.
Are you using QT for cross-platform compatibility or some other toolkit?
It's all native.
Pinning is supported, just temporarily disabled. File support is not great right now. Only inline images are supported.
But the goal is of course to have full feature parity and more, so follow the development :)
A lot is going to be done by the end of March.
Not on Ubuntu/Arch/etc... :)
[0] https://www.glitchthegame.com/
- Resource hogging - Buggy iOS app (especially on iPhone X) - Missing accessibility features - Lack of native app
They've taken $0.75bn in funding over 10 rounds and still suffer from some _basic_ issues.
- Mentions: Many times I've tried to mention someone but Slack goes and picks the wrong person. If I'm typing `@johnd`, then it should be fairly evident that I'm trying to mention `@johndoe`; don't make me go through that UI when you should have enough info already.
- Buggy snippets: Why do I have to go through a slow UI just to paste some code, when triple-backtick should be enough?
- Triple-backtick: No code highlighting. And just try to copy its content; you'll be surprised when your clipboard looks as if passed through an `s/\n/\n\n/g` filter.
- Scroll up: Scrolling up many pages above causes some weird jumps.
---
Incidentally, the Discord people got all these things right.
What is currently the mainstream opinion regarding XMPP and good security: is it possible? Is moxie an outlier in saying that it's not possible, or is that the mainstream opinion too?
Daniel Gultsch, the author Conversations (XMPP Android App), wrote a response:
https://gultsch.de/objection.html
He was not really speaking for what was best for the community, you can read the blog post as marketing material.
[1] - https://signal.org/blog/the-ecosystem-is-moving/
[2] - https://signal.org/blog/whatsapp-complete/
[3] - https://signal.org/blog/allo/
[4] - https://signal.org/blog/skype-partnership/
This is a very uncharitable interpretation. Signal is arguably more secure than the competitors you mentioned, not just a "proof-of-concept".
> He was not really speaking for what was best for the community, you can read the blog post as marketing material.
In the blog post Moxie mentioned usability concerns due to federation, which directly affect users.
I totally agree with article itself, but this is rather moot point. Slack still provide full history export for free and it's rather easy to self-host said history. IRC and XMPP didn't made it any easier to extract that data.
I aware that export doesn't include private messages, but it's not what Slack used for mostly anyway.
Wrong. If you want to export messages earlier than the last 10k, Slack will extort you to the tune of $10 per user (even if they aren't active). And that's per fucking month. Does your startup/club/laboratory of 29 people have $290/mo of income to incinerate, when you could just host an AWS IRC server for 1% of that?
As far as I know, Slack never pitched as the guys who would rescue IRC out of obscurity and into mainstream. If they did, then you could perhaps fault them for giving up too easily without serious effort.
The iOS client developer needs to run a proxy server that will accept notifications from XMPP servers and wake up the client via APNS (this is required by how APNS authentication works).
The client can connect to any server that supports XEP-0357: Push Notifications [0], and can register the respective push proxy with the XMPP server.
ChatSecure for iOS [1] has implemented this approach, but the client still needs some more polish.
[0] https://xmpp.org/extensions/xep-0357.html
[1] https://chatsecure.org/