Tell HN: Slack decides to close down IRC and XMPP gateways
Hello! We have news to share — we've decided it's time to close down the IRC and XMPP gateways to Slack.
After years of evolving, Slack is at the point where the gateways can no longer handle all of our features or security needs.
If you've been using the gateways for accessibility reasons, we're glad to let you know that it's now possible to navigate Slack by keyboard and with a screen reader — and we're making more improvements on a continual basis.
Still, we know this is a disruptive change, and we want to help with this transition in any way we can. Please follow this link to learn more about the upcoming changes:
slack.com/account/gateways
11:14 -!- End of MOTD command
623 comments
[ 3.2 ms ] story [ 275 ms ] threadhttps://github.com/wee-slack/wee-slack
What route did you go?
Maybe I'll even finish it one day :)
[0] https://github.com/wee-slack/wee-slack
Perhaps it's time I give weechat a try :/
But as far as I can see nobody has written a Slack-API plugin for it, yet.
It's a symptom of the centralized world the internet has become.
https://wiki.debian.org/InstallingDebianOn/Microsoft/Windows...
Embrace / Extend / Expunge
Sure, the Linux subsystem is "Embrace", but a lot of things can be embraced without extended or extinguished.
Do you expect the Linux kernel to continue being runnable on contemporary laptops if decreasing numbers of users are even attempting to boot it?
The same thing happens with Docker on Windows in the datacenter. If users embrace the MS offering, and it runs their Linux containers, there will be less resources going into Linux kernel development from the server world.
Google going the fuscia/zircon or whatever it's called now route further diminishes the resources put into the Linux kernel.
I don't think there's any reason to reject the observation that there's a lot of competition in this space and a number of these moves substantially threaten Linux's relevance in the long-term.
The exodus of users to OSX has already been quite harmful to GNU/Linux's progress on the desktop. If it weren't for Intel investing so heavily in Linux kernel development I don't think we'd have modern wifi or gpu support, not from the community alone.
Much of what I describe above is the Embrace phase. Once a sufficient number of users are running their Linux userspace components on proprietary underlying kernels, the relevant companies can start investing in "improving" userspace in incompatible ways only their kernels implement - perhaps in patent-protected ways - Extend. Voila, you're locked in. And since the Linux kernel wouldn't have the development resources it once had, it just falls behind into obsolescence.
Slack advocates could say, "Don't worry, you don't have to switch. You can just keep using your IRC client with Slack. Everybody else will have a web UI, which they prefer, and you can keep using Irssi. Everybody wins."
Are we doomed as a community to be surprised every time a company with power squeezes?
[0]: https://www.irccloud.com/
Loads of companies (including Facebook and Google) are trying to "fix" (read: kill) your email inbox.
https://www.appleworld.today/blog/2016/8/8/hey-apple-any-pro...
> We are focused on making Slack accessible to all people. Over the past year, we've made great progress in improving both the keyboard and screen reading experiences in Slack. We know many users have been relying on IRC and XMPP clients for a more accessible experience — but our goal is to build all of the accessibility features you need directly into Slack.
Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team.
And it's completely absurd that mine is currently using 1514MB of memory.
If I weren't required to use Slack on a day-to-day basis, I absolutely wouldn't solely on principle.
I've switched over to using mattermost, it can be (and is) self hosted so I'm not as worried about slack getting hacked (again) and leaking our info/taking control of our systems with chatops.
The downside is; mattermost is not a strong replacement. I wrote a bot to basically do a large part of my job for me, and coding against mattermosts websocket protocol and dealing with authentication has been messy to say the least.
Slack is a joy to code against and use from a UI perspective when compared. (sadly, as I don't like it for ideological reasons)
Here's a fun one: say I use the MIT binaries, then debug a problem by reading the AGPL source code. What legal position am I in? (If you have an answer for that rhetorical question, by the way, you haven't thought of the problem long enough.)
https://github.com/mattermost/mattermost-server/blob/master/...
They launched exclusively AGPL and then made MIT as a concession after discovering that a number of companies outright ban AGPL and won't pay for it unlike MongoDB, but licensing binaries differently than source code is not something you come across often.
http://cultofthepartyparrot.com
On a side note, Last Chance to See is a great book (Douglas Adams) and show (Stephen Fry), highly recommend both of them.
[0] http://knowyourmeme.com/memes/party-parrot
Standalone client and its helpers are sitting on ~800MB committed on my install of High Sierra. Might be worth a shot.
To put this in perspective, I was talking this week to a developer who was essentially apologising to me for a new feature that was going to require insane amounts of memory. This is for a process to handle literally millions of users.
How much memory was it? 3G. Per "instance" of which we need 2... Again, for millions of people.
Want inline pictures? Well, Textual has had that for a long time, irccloud's webUI too.
The amounts of memory that users are reporting for Slack are all several times higher than the entire RAM of the first computer I started using my MSNP client on.
I had to walk 10 miles to school in the snow! Barefoot! Uphill! Both ways!
or
GET OFF MY LAWN!
I think "team software engineering" plays a big part of this, if not even the main reason. When one developer is working on a program, the person tends to be able to keep track of program flow, memory usage in their head and know when things are about to go out of bound, memory shoots up, etc. When you have a whole team working on a huge piece of software, each person is working on one part of it at a time. If your feature grows memory usage by 100mb, it's not a big deal. 20 people doing that, memory usage just grew by 2gb. And then in modern software dev shops, you typically put devs on different features on a weekly basis. (unlike traditional, slow, non-agile development where a person owns a certain module/component and is the expert and works on it for years) When you move to a new feature, you need to pick up on all the details of how it works previously, and you build your stuff on top of it. You don't have context of the really nitty gritty details someone who wrote the original framework thought about. You're going to do something less than ideally efficient. Unfortunately, this is just the way modern team software engineering goes.
Or of course, you can still just say it's a Javascript problem and mock JS; which also has merits.
You're not wrong, but perhaps that's an indication that software companies should use language & environments which enable them to have fewer developers, and enable those developers to keep track of things like resource usage?
Whereas traditionally you would have an engineer responsible for part of the application as time goes by, making sure that it works better while maintaining quality.
Then don't freaking do that. There's no reason to make one huge app with thousands of features that justifies teams of dozens of devs instead of tools that do just one thing (and can be used in a modular way) correctly and nothing more.
Actually, there's one terrible reason: the bigger the app, the higher the wall around the garden and that serves as a justification for the price tag. It's the wrong way of doing things because business. It's exactly the same evil principle as the one which is at work when the sugar or the tobacco industry do their slightly questionable stuff.
A big part of why this occurs is Electron. Same with any app that's basically a browser app: memory usage is out of control relative to what the application does.
Case in point: https://arcade.ly/games/starcastle/ (disclaimer: I wrote this). Uses 284MB, for a version of a vector arcade game from 1980. Same issue with my version of Asteroids too: https://arcade.ly/games/asteroids/. Some of this is down to the idiotic way the Web Audio API handles compressed audio, but with Asteroids I have to pre-render a lot of images because canvas 2D performance isn't that great with drawing primitives. Even excluding these issues, and allowing for several canvas layers at 1366 x 768 x 32 bits per pixel, double-buffered, and the thing still seems to consume quite a bit of RAM.
Welcome to the wonderful world of JS/CSS/HTML5 apps.
RAM prices have plateaued due to production shortages in the past few years, and many (high-volume) $200 laptops/Chromebooks do not come with 8GB of RAM.
On X, this means emacs-slack displays images, emoji &c. just like the web or pseudo-native clients do.
[0] https://github.com/yuya373/emacs-slack
If it's so hard to write native macOS, Windows, gtk+ or Qt apps — maybe that's a fault of those development environments. Granted, 'display sequences of text, optionally with some images' is kinda in emacs's wheelhouse.
But seriously, how hard would it be for a sneaky dev to make emacs with emacs-slack into a normal person application with clicky buttons and no ugly gnu? Could be worth a lot of money, or at least github stars.
Well, out of the box emacs has a clicky-button toolbar: https://i.stack.imgur.com/ml0UE.png
And using the keybindings folks expect from Windows is part of modern emacs: https://www.emacswiki.org/emacs/CuaMode
As an aside, I absolutely love the idea of every new app being written atop emacs, but I'm an incorrigible emacs user. I use emacs for email, for git, for slack and (often but not always) for web browsing. Oh, and also to edit text.
It's still 100% an improvement over what we used for chat before (Skype), but I'd be much happier running IRC or XMPP hosted on one of our servers. The boss decided on Slack instead as it's less maintenance on my part. I don't mind the extra work involved with running something we control, but the company wants me on other projects.
Sometimes when trying to log in it would say that the (saved) password was incorrect, the user would go change it in their Microsoft account and it still wouldn't take it, then a few hours later it was working fine again.
Slack also has much better search, and their support for attachments is dead-simple. Sending a file on Skype was always a chore that felt like it was 1999 all over again, but on Slack it's literally drag, drop, and collaborate.
As I said before, Slack wasn't my first choice but it's a good platform for what it is. I don't like that our conversations and files are stored on their servers, but I doubt anyone at the company is sifting through our stuff looking for dirt or valuable info on a small business with 10 employees.
The only solution on Linux that implements audio, video and screen sharing is Sky (http://tel.red/), and it's incredibly flaky.
It doesn't help that the client hasn't had much more than cosmetic changes in at least five years, and is largely abandoned for Microsoft's kludgey Slack competitor.
When something bad happens, usually it is network infrastructure related or some IT experiment going on.
https://github.com/stanfieldr/ghetto-skype
Spritesheets can be disabled under Advanced.
Maybe it helps, sorry I have no before/after but my Slack is sitting at 300MB right now and I deal with an high number of very active channels.
You must be overlooking all the helper processes.
You're talking to one
Though I'm not convinced that greybeards are any different, just the ones you find caring about it on the internet.
My dad's a 68-year-old old school embedded hardware developer and he'll use whatever toolkit works. I reckon most people in the world are like him and not obsessing over tools, despite what HN makes you think.
The reason why accessible users use JAWS is that it works across the entire OS and all the programs you have installed; start menu, PowerPoint, web browser, control panel, Google, etc. etc. The problem with the native accessibility tools is that it fragments the accessibility experience; you have one tool for OS operations, another tool for browser work, another tool for this, etc.
So that being said - it is a waste of time to target the native APIs for accessibility. Your target is JAWS and that's it. In fact, I'd argue that JAWS is better at reading HTML than native apps, so Slack is doing the right thing by moving all their apps to the cross-platform one.
[0]: https://nvaccess.org/
https://accessibility.blog.gov.uk/2016/11/01/results-of-the-...
Of course, there's always software that costs absurd amounts of money for seemingly simple things; IDA comes to mind. I'm not excusing it, but that isn't to say that it doesn't exist.
Their moat is that the addressable market is too small for investors to bother investing in.
my recollection from speaking to a blind acquaintance is that it is subsidized by some government agency for personal use, and businesses buying it for blind employees are just stuck with it as an ADA thing.
The native screen reader built into windows doesn't work well with web pages, so you have to get your own tool (sorry, screen reader) specifically for reading webpages. The browsers all have some extensions for this. So yes, now you have two tools to use - the native screen reader and the browser. And they both are garbage (I've used both while my license for JAWS was pending).
Making software accessible just on Windows is complete bullshit and should be downright illegal.
Slack is a proprietary protocol created to make money on its proprietary service.
I am glad they are making it more closed as then maybe more people realise that centralising your communications on top a VC funded, for-profit company is not a good idea.
And I doubt _any_ business has centralized their communications with Slack. I’m sure they are still using phones, and email and face to face communication.
Slack's rise continues to baffle me. It's not good or widespread enough to replace email, Skype messenging, SMS or phone calls - so it's yet another thing I have to stay on top of at work. My life would honestly be easier without Slack.
Baffling that so many people still use it as yet another mode of transportation.
Disregarding the technical side of things, Slack is a great tool and it is quite understandable why it stuck: people like it.
I'm not sure how serious to take you when you think Skype is better.
Or you're signed into Skype for Business on multiple devices. You wouldn't expect to receive instant messages on all your devices at the same time, would you? Because that's really asking for a bit much in 2018. We're not wizards, you know.
Every time I have seen Slack as the primary communication vessel, I have seen a company that fails to ship on time and has a hard time with knowledge sharing. The medium is the message!
At my current company, the main way to reach someone is Hipchat. We have a large percentage of remote workers, so face to face works for some people, but not everyone. You have to be on chat, and you have to be checking it regularly. We still use github, JIRA and confluence for work, but almost everything passes through chat.
Then why don't you switch to a good client? The reason email works so well is that you have that freedom!
Relay is open source, built on top of Mattermost. This means you can host Relay yourself. https://relay-chat.com/
The part of software in Relay that makes mattermost SaSS is open source too.
Can't wait to use the term "AIMd" on "Slack" (what a stupid name BTW) in 10 years.
Not just that, but it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days. So yeah, I take this promise with some skepticism.
So either this is a lack of priority and disrespect to a part of their users or some level of incompetence.
I might sound harsh about this, but imagine being a blind software dev that's supposed to work with Slack to participate in teams. Every day you sign on to your team it's possible that the Slack devs break something and you can't function. And now they closed the escape hatch.
A userscript hammered out in a few days is not really that comparable to incorporating accessibility in a flexible and sound way across a codebase.
Where one is dependent on the current representation and types of features in the app, the other touches pretty much everywhere in a code base that might be split across different people or teams that have other business goals to accomplish.
The scale of work is not really as comparable as they may seem at first glance.
So, contrary to what you said about lack of priority and disrespect, I think it's admirable that they take the time to add these necessary accommodations in a way that ensures that they'll be appropriately maintained and present with future iterations.
There is definitely a poison in our profession, I definitely have to fight the urge to make sure no future changes will break something, instead of just budgeting time to fix breaking changes later. Especially since no one seems to remember when we all agree something doesn't need to be bullet proof. Just today there was an expression of disbelief when I reminded people I'd built a tempermental UI for some internal tool. Never mind that it was a conscious decision to prioritize a better UI later if we found the tool useful and found the UI was causing problems.
The difference is that they don't work in the same office as Slack. They'll never hear about all the important, completely justified reasons Slack decided to release a bad UI. They'll just notice it happened, and conclude that Slack must hire incompetent UI developers who didn't realize it was bad. Any product with a large customer base has to be pathologically averse to things like this.
(Note that 'purpose' might be 'allow us to process this one batch of files' or it might be 'provide a stable, maintainable infrastructure for our product for the next 20 years'. It's just important not to lose sight of that purpose either way!)
However, I would imagine that as a company, if you require employees to use specific software as a condition of employment and no accommodation can be made, you might run into trouble as an employer.
The web (and web apps) are all about providing an experience. I don't want an experience, I want a reliable tool.
Honestly I prefer text-mode browsers when I can use them, but that ship has mostly sailed. I've been involved with the development of edbrowse; the author is a friend of mine.
I think you should really have someone who hasn't seen the app test with the blindfold.
Is that double blind, or just single blind plus literally blind?
I'm not sure how that would work for software, but it sounds like a much larger experiment than is currently customary.
When designing an application, forget the visuals: design the flow of information, and the interactions. This is a surprisingly good facsimile for mobile-first thinking, as it follows similar principles: in both cases, you have a restricted amount of information to display, and have to design to deal with that.
Once you've got the information flow, step from there to visual elements, and ensure that as you build, you're baking in ARIA support and your testers are interacting with it using VoiceOver/JAWS.
At the end, the fact is you won't have anything perfect, but you'll have something better than the majority of sites out there. The reality is that perfection is impossible, but if you bake inclusive thinking into your app from the get-go, it's pretty straightforward, and you usually end up with an application that is less confusing and overloaded with information for your visual users too.
If you leave it as something to slap on at the end, it's almost always impossible.
The hard things like focus control require manual testing, ideally by a skilled user of AT.
Have you looked into pa11y and its CI integration [1]? It's a good start but it cannot replace properly testing your UI with accessibility in mind.
[1] https://github.com/pa11y/pa11y-ci
I'd love to hear more about this (the good/Bad/ugly). My guess would be irc is head and shoulders above anything else, due to established standard + myriad of solid clients.
But what have you found so far?
I've given the CI deal a good amount of thought. You'd have to go through the trouble of:
- Provisioning a Windows VM with specific versions of browsers (e.g. IE11) and AT (e.g. JAWS 17, the versions differ quite significantly)
- Writing an automation suite that is capable of controlling the browser and AT (Selenium probably does fine), but crucially interpreting the feedback from the assistive tool to check for correctness. This is tremendously hard. Either using some debugging APIs if any exist in the various assistive tools, or reading memory / reverse engineering using IDA, or capturing the audio output to the sound card and running it through speech recognition to figure out if what was said by the screen reader is what you'd expect. With something like Dragon Dictate you'd have to figure out how to trigger voice commands.
- Expose the VM using an API that you can call from your test suite
- `expect(jawsOutput).toBe("Type in two or more characters for results.")`
That's a potentially tremendously profitable SaaS offering (to the right companies), if someone can build it.
[0]: https://accessibility.blog.gov.uk/2016/11/01/results-of-the-...
I used JAWS and Windows IE11 as a specific example because that's a popular combination with screen reader users. If something works well in NVDA and FireFox on Linux it does not follow that it will work in other combinations, at least in my own testing with things I've worked on in the past. Though targeting the low hanging fruit to begin with is how I'd also start if I was building something for this in earnest, ideally I'd want to automate testing with all the popular combinations that I expect users to have.
Being “able-bodied” is only temporary, for everyone. Any dev that doesn’t realize this will eventually come to regret it as they age.
(My accessibility issue is much smaller: I merely avoid using the mouse cursor, because the keyboard is much lighter on my wrists and hands than the mouse, trackpad, or trackball.)
Thank you for this, this made me laugh. You are not alone in this reaction.
I've occasionally tried to set up a workable system so that I could program blind. I have vision problems where I get ocular migraines unless I have my system set up with a huge font and very high contrast anyway, so I often think that it would be nice to program without looking at the screen. However, I have yet to get my system set up in any way that works. Accessibility has a long way to go. Every time I've tried to set things up I wonder how a blind person can possibly get to the point where they can even start. It's so frustrating.
Actually if anyone in the know is reading this, I'd appreciate a pointer to the easiest to set up Linux system. I wouldn't mind giving it a try again.
NSDictionary *myCompoundedWord = @{@“key: [NSNumber numberWithInt: 7] };
And know that it’s missing the terminal “ in the string and has an extra space after the ]?
Seems very difficult. Would be great if it could understand the language enough to verbalize it at a higher level.
n s dictionary star my compounded word equals at left brace at left quote key colon [pause] left bracket n s number number with int colon [pause] 7 right brace right bracket semi
It's a lot to absorb, but people do program productively this way. For example, the NVDA screen reader is itself developed primarily by blind people.
[0] - http://emacspeak.sourceforge.net/
Even better would be tools that are aware of indentation, that you can't see the indentation, and help you debug problems without having to make it so explicit all the time. It could get really weird / grinding to have to listen to monotone speech that's constantly changing pitch.
Some projects developed exclusively or primarily by blind programmers do make odd indentation choices. A couple of my blind programmer friends prefer single-space indentation, or at least they did the last time I worked with them (using Python). NVDA uses tabs for indentation, which breaks with the Python convention of four spaces per indentation level. But blind programmers are perfectly capable of following the usual indentation conventions when working with sighted programmers.
Finally, I don't know of any blind programmers who like COBOL. I'm sure there are some, probably working at banks like their sighted counterparts; I just don't happen to know them.
Another point is that I imagine it takes your complete focus to listen and comprehend single characters at such speeds, so you will be super-focused on the task when you're writing code.
We, as the programmers with sight, can read code without getting anything out of it, if we're not focused.
That's somewhat similar to how ed works. You choose a line number or range and print those lines to the screen.
http://edbrowse.org/
I mean that might just be how you code, and GP does not code that way...
https://youtu.be/iWXebEeGwn0
Also now that Discord exists, I would never do a voice chat in Skype either. A substantial portion of every Skype call I've ever been on was people apologizing to each other for the bad audio. Discord apparently just has better signal processing.
Skype for Business does. But... not the Azure/Cloud version; you have to host it on-site, and MS are rapidly replacing Skype with the less feature rich (if that's even possible!) 'MS Teams'.
chances it will be around in 10 years? I would say 25%.
None of the chat apps ticks all boxes, which is why we need a universal client that puts the user back in control like in the Trillian/Adium days. And no, matrix+bridges is not that solution.
[0] - https://github.com/mumble-voip/mumble
[1] - https://wiki.mumble.info/wiki/Main_Page
* User authentication
* Support for multiple concurrent logins by one user
* Persistent, searchable history
* (Ad-free) file and image sharing built in
* Simple integrations, like webhooks, built in.
In other words, Slack is like IRC+NickServ+Irssi+Screen+Imgur, except easier to use, in the sense that you don't need to know key combos like Ctrl+A+D or Ctrl+Alt+2, you don't have to figure out how to send such combos from your phone's terminal emulator, and you don't need access to an always-on server to run your screen session.
Of course, it's not all good; Slack has a bunch of opinionated design choices, like a channel it's impossible to leave, no ability to block users, no off-the-record option, and suchlike.
They even give you a hello world sample curl when you opt to add the webhook. At the simplest you can just replace the hello world text and bam -- you're sending to slack. Just takes a very simple json input.
It's closer to Slack is like DALnet.
That said, this is a money grubbing exercise that isn't justified by any technical means.
I worked with two blind systems people for close to 5 years - we were all working remote, so initially I had no idea they were blind - and subsequently learned from them about their struggles and frustrations dealing with shitty or nonexistent accessibility features.
And with assistive devices’ drivers that were broken, or not updated since Windows State of the Ark version, or not available on Linux or Mac, and so on.
These two people dramatically improved the accessibility features of the smartphone product that the company sells, by reporting the issues they found while dogfooding it. They raised the awareness of many people, including me, of the challenges of the blind, particularly in technology settings.
As a result, I learned ‘dot’ (graphviz) pretty well, and became much more text-centric in other ways (e.g. using markdown, avoiding images when possible, adding alt text).
Slack has done the community a disservice by dropping support for open protocols like IRC and XMPP, which support text-based interfaces that work well with screen readers.
So screen-reader usability is still a thing. The fact it's not using a proper standard open protocol is a problem.
[1]: https://github.com/yuya373/emacs-slack
[2]: https://github.com/wee-slack/wee-slack
XMPP is an example of a federated protocol that advertises itself as a “living standard.” Despite its capacity for protocol “extensions,” however, it’s undeniable that XMPP still largely resembles a synchronous protocol with limited support for rich media, which can’t realistically be deployed on mobile devices. If XMPP is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world?
Like any federated protocol, extensions don’t mean much unless everyone applies them, and that’s an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren’t consistently applied anywhere. The implications of that are severe, because someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them. It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience.
IRCCloud is using only standard IRC features to implement their Slack gateway that offers all features of slack - including reactions and threads.
Federated protocols can move extremely quickly, I've seen that myself recently.
A really popular mobile Jabber client will suddenly have the extensions it supports become popular with everyone else. Conversations looks nice.
As for why some set of extensions hasn't been brought up to modernity, that answer's simple: nobody cares about xmpp enough. Maybe just some users, but fuck those guys, they don't build anything.
> Will
Man, xmpp has been out for twenty years now.
Until you have two popular apps that implement two different extensions that accomplish the same thing. Now everyone is stuck implementing two, three, four extensions to display the same content. God forbid there's a new version of an extension that's backwards incompatible.
> addressing with user-owned identifiers like phone numbers
Phone numbers are owned by telecoms, not users. Sometimes they're transferable between telecoms, but not always. I, in particular travel internationally often and do not maintain phone service in the same country continuously. I've had to change phone numbers with Signal and Whatsapp a couple times now and have not found it to be a particularly friendly experience.
I got a free Google Voice number and might use that in the future, but I had to tie that to another US-based phone number. What will happen if someone else starts using that number, especially if they also connect a Google Voice account to it?
I don't know that I have a better design in mind, but using a phone number as an identity has some nasty edge cases.
1) get US phone
2) register google voice to US phone
3) stop paying for US phone
4) you can't de-register you US phone, unless you register a new one
5a) if you never sign up for a US phone, anybody can get assigned that number and click "forgot password" on your google voice.
5b) you get a new US phone: go to 2.
that is true for every single service that ties you up to a phone number or that has phone number as recovery option.
I've also read using Google Voice is highly recommended for things that require a voice or text number since it's very difficult to get hold of someone at Google that can be socially engineered. Much easier to scream at somebody at Verizon, etc.
The cheapest I've seen slightly below $2/month, but all the super cheap carriers are very volatile businesses and you can't expect to keep them more than a few years.
Seeing as you don't really own phone numbers in the sense you own domain names, any permanence is limited by the life span of your service provider.
Don't take things like that too seriously. That's just the result of the reality distortion field that comes with sitting on top a huge database of phone numbers.
Simple: usernames. Humans are not phone numbers. Phone numbers are the IP addresses of legacy phone networks.
http://tox.chat
A lot of countries require require registering the phone number to your name.
Relying on phone numbers as uniqie identifiers especially in "crypto" hipster apps (Signal) is stupid bordering on malicious
If said malicious actors pwn the phone of the person you were talking to, suddenly they have a pretty good way of mapping a contact called "My Best Friend" to a human through billing records.
Or even easier, they type the phone number into Google and find that the Syrian dissident they've just arrested has been corresponding with the NYTimes or BBC.
If they know only that they are talking to anonymoushackzor@gmail.com they could, uh, get Google to release their IP address. Google are fairly unlikely to honour a legal demand for disclosure from Libya or North Korea or some other tyrannical/fucked-up hellhole.
I like Signal, but I'm not totally sure about the threat model.
* They're not portable. My username here is Zak. It is on reddit as well, but I think that's the only other place. If I don't discover a service within it's first week of operation, I won't get that username, and many won't allow it because it's "too short".
* They don't tap into users' existing contact lists. I've discovered several people I know using Signal because I had their phone numbers stored in my phone's contacts.
But if a new communications protocol is to replace the legacy phone network, which I consider desirable, it probably shouldn't use identifiers tied to the legacy phone network.
It would at least have been nice if the 'extensions' had a required way to be opaquely handled and saved as files so that other tools could use them.
If every major messaging service eventually does this maybe those decentralized and standardized protocols are the problem.
(I'm not saying the current open protocols are perfect, or even close, however - 100s of closed chat protocols have been built and rebuilt - that effort would have been better spent in the open IMO. Obviously, investors and similar business functions see things differently though.)
You're joking, right?
Have you not noticed any of the pain that anybody trying to make cross-platform app goes through, and hence the huge popularity of cross-platform frameworks?
How many companies still maintain native iOS and Android apps? Lots. Qt even feels (mostly) native on GNOME desktops these days, if you can't afford to develop a 100% native app for Win, Linux and Mac then at least use a real toolkit that gets you 80% of the way there whereas Electron gets you 0%.
At the end of the day Slack has to optimize for growth and there's a huge list of features that will bring more ROI than native clients which will require trebling the size of the code base.
If you're going to do something do it right or don't do it at all.
For example, the desktop app will show notification count in the dock.
Imagine if all of your apps had a browser version and you could always pick between a tabbed version vs standalone version. To use the tabbed version of everything would be like using an AOL app back in those days where you alt-tab to the AOL virtual window and then find the app you want within it while wishing you could just use the OS' window manager system.
[1]: https://matrix.org/docs/projects/client/quaternion.html
Feel free to articulate your issues with such apps. So far, no one has really done that in the various comments online disparaging Electron.
What? Every time Electron comes up, people bemoan its battery and RAM usage.
There are a couple of cases where you can avoid that in the text editor and source control space: Sublime Text is cross-platform and native, and so is SourceTree (although it's become quite buggy). So just avoid GitKraken, GitHub Desktop, VS Code, Atom.
I made no such claim. I was just providing a legitimate business reason for going the Electron route.
That's the tradeoff, and I wish companies would be more honest about it. But a company with as many engineers as Slack doesn't really have an excuse beyond "we want to spend less".
Things are usually hard not because of some lofty technical goals, but because the sum of all the papercuts is hard. It's just developer hubris to look at the trade-offs someone makes and say (on HN of course) "meh, these other trade-offs aren't even that hard, c'mon!"
It's only ~100 KB(!)
It will be out of alpha this month.
https://eul.im
> What language is eul written in?
> C. There's also some Objective-C for macOS UI.
https://eul.im/
"C. There's also some Objective-C for macOS UI."
> Second, it's not open source, and I'm not sure I'm comfortable trusting such an app with my login credentials.
"eul doesn't ask for your passwords and doesn't store them anywhere. Authentication is performed in a browser directly on the messenger's website."
For now you can run it from Terminal.
I see a lot of companies drawing that conclusion from such premise (and you're using C, which really decreases the odds that my data is really safe).
Using that sentence on your main page makes it look shady. Specially if you're not a security company.
IMHO, if you remove "Your data is safe" it will look much more professional.
https://news.ycombinator.com/item?id=16544045
[0] https://github.com/erroneousboat/slack-term
Basically, it is hosted mattermost. We've written our story of how we created Relay by escaping slack: https://medium.com/@deobald/we-created-relay-by-escaping-sla....
There are bux fixes, and feature improvements pouring into mattermost from around the world, and we get them in. We're building integrations, bridging services and other slack features (which will also be open source) into it on high priority.
There's https://github.com/42wim/matterbridge, which provides bridges from mattermost/relay to practically all other messaging platforms out there including IRC, Telegram, Gitter, etc. We're building a SaSS for this too.
Disclaimer: I'm a part of the Relay team.
https://twitter.com/harisamin/status/727634194814373889
I've posted about it before here on HN but wasn't sure if there's enough interest
It feels like a mixed blessing though, as it is a nice excuse to detox from this mess.
Why isn't there a public blog post about this? Why is the "more information" page behind an auth wall?
But at least I didn't have to deal with inline images and animated gifs over the gateway.
Riiiight. And how many clients do you know that have that? Or read receipts? Or file sending? Or... Or...?
There’s basically just one client that supports modern XMPP features. So no, it’s not the client developers’ problem. It becomes the end-users’ problem. And they will abandon XMPP in favor of solutions that don’t have tgat problem.
Now you're arguing about something completely different. It's not like it's a death sentence if some RTM API-consuming app is not capable of something - why does it suddenly becomes an issue when we switch protocol to XMPP?
There’s exactly one XMPP client (Conversations for Android IIRC) that supports all the XMPP features (many of them in still experimental XEPs) that make it barely suitable for a modern mobile-heavy world, much less for anything else.
So yes. When you say it’s developers’ problem to develop clients, it’s not. It immediately becomes the end-users’ problem.
Some people like slack or telegram because they provide an API for BOTs. Something IRC has been open to since the begining.
Non power users might have trouble using IRC with the usual clients (mIRC/irssi/bitchx).
Today a family member, not technical and 60+yrs asked about "that tool" that is like whatsapp however it allows users that just joined a group to read old messages. He was referring to slack. He wanted to create a group and when new users from his company joined, they would be able to read whatever was written on that group.
So with this in mind, i think what would really work (also) is to have something on the front of IRC (some bouncer) with a pretty UI that logs everything and allows new users to connect via mobile, standard irc clients, and also send pictures, and read backlog (stuff slack does). However the backend chat server should be the decentralized existing ones, efnet/freenode/etc.
So maybe its time to re-invent slack and make a pretty UI to access usual standard IRC. ie. a new slack that uses old irc networks (decentralized networks) as its backend. But also allows users to talk from mobile apps, browsers, etc
TheLounge - https://thelounge.chat (FOSS, self-hosted)
IRCCloud - https://irccloud.com (mobile clients OS, hosted)
At the very least it looks and feels far more modern than, for instance, mIRC.
I'll stick with Slack.
* https://matrix.org/
* https://riot.im/
It gets a bit more complex if you want to run your own server, but that's not something you can do at all with Slack.
For a small corporate team that wants to pilot a chat program, like in the original comment, the gulf between Slack setting up your own private workspace with a few clicks and a room that has all of your chat history exposed to any user that knows the room name is pretty large.
I would love to see riot or matrix give you a few click options to have them host your own private matrix server, as that's a big obstacle for corporate customers who don't have the resources (human) to spin up their own servers (domains, adding ssl certs, adding nginx, etc.) just for trialing a chat program.
Separately: we're working on providing a "one-click" homeserver hosting option with a free trial precisely of the kind you're asking for.
One problem with all these closed client apps slack (with this update)/whatsapp/telegram is that there is no way to verify/audit it is actually doing proper e2e.
Users must trust the X company that they are really doing proper e2e.
These apps should allow users to download a plugin and use that to produce the e2e. Then the user would be able to download an open sourced audited plugin that encrypts the messages before they hit the whatsapp/slack/telegram company servers.
So for instance, if this was possible, everyone on a group would download and install the plugin that runs on top of whatsapp/slack/telegram and share an encryption key that only they know about. And do the same for conversations between 2 people.
There must be some point of trust, however with the current situation, it is hard to trust e2e code no one is able to audit.
Or just open the protocol so everyone can use and create their own clients and their own e2e mechanisms. Which is what IRC is.
0: https://security.stackexchange.com/a/49802
The freedom to choose is one of the reasons people wish slack would open source their protocol.
[1] https://convos.by/
I've never used Slack but these name drops are all familiar.
Back in the good 'oldays of Eggdrop? It's amazing that Slack was "backwards" compatible with IRC for so long.
But honestly, their API is mature. No need to be backwards compatible. Easier to sell when you are in control of access and client.
(Arghh... I'll probably be downvoted to hell for a flippant, drive-by comment, but what the fuck... We all know that HN hates comedy.)
Also, see https://ircv3.net/irc/
It's relatively easy to see how these engagement numbers can be leveraged as a sales tool.
2. It's absoletely as assinine and distracting as you imagine.
Aside from missing native clients mentioned in other comments my biggest pain point is their awful implementation of threads. Every time I think: They must be kidding, they can't be serious, that's just a bad dream. A few examples:
- The only place where you get noticed about responses to threads is the "New Threads" view, which makes it easy to miss responses, when you have responses to multiple threads waiting to be read.
- While having the "New Threads" view open, new messages aren't shown automatically and you have to click a link to show them.
- "Threads" for snippets and files are displayed directly in the channel the snippet/file got posted in.
- You can't post snippets and files in Threads.
- You can't use "/me" in Threads.
Instead of blaming Slack, why not accept that the open protocols indeed suck? IRC does not specify encoding, netsplits are a common issue, file sending sucks, etc. XMPP also has file sending problems, does not play nice with mobile, is fragmented (not every client implements desired extensions), etc.
Why not accept that there are legit technical reasons why existing open protocols are unacceptable?
We should not be blaming Slack so much. If we want to make a difference we must come up with a better open protocol that satisfies all the requirements. And it does not end there: there must also be an open client that normal people actually want to use, and there must be tons of marketing to promote it.
Stop complaining about companies not adopting open protocols and do something. Dominate the world using open protocols, then the walled garden companies will follow. It is not easy, it may even feel wrong, but it is the only way.
Volunteers don't have the marketing budget or, even the technical budget to compete with slack.
It's basically a non-starter unfortunately; and when they do come around (XMPP with push and decent extension is not bad) people are so hung up on the first implementation that they won't look passed previous shortcomings. It's easy to tar something when it doesn't have a marketing team behind it.
However, this is simply untrue:
> Dominate the world using open protocols, then the walled garden companies will follow.
When you are Slack Inc and the only differentiator you have is that you are in control of how chat works, why on earth would you switch to a protocol that you don't have full control over?
If Matrix were overwhelmingly more popular than Slack, they would integrate with Matrix. But Matrix isn't more popular than Slack. (Matrix isn't even as popular as IRC, despite being a better product than IRC, as far as I can see.)
Bait
> Now that Slack is much bigger than all IRC and XMPP traffic combined, the integration is no longer worth its weight in code.
Switch
edit-001: fmt changes.
Are you planning very many edits?
The GP is calling for a slack competitor to launch and gain popularity with the help of an open protocol. Once the pendulum swings back towards openness, Slack would be forced to adopt it to stay relevant.
If you value your freedom, use the open source RocketChat, instead of Slack.
This is crazy. The keys should be per person, not per device.
To be clear, there are several hiccups with e2e at the moment, but they are being worked on (from what I can tell).
This seems like a trivial gain for lousy UX, since it's possible the account and the device is compromised.
Having per-device keys also means that the server cannot decrypt your messages (because the identity key is not used for communication, it's just used to register new keys that clients will encrypt their messages to). Having a global decryption key stored on the server would be a less secure design.
How you solve those problems impacts and is impacted by the messaging protocol. If Slack is going to keep moving fast on features that matter for businesses, they're likely to keep needing protocol features that wouldn't necessarily be the priority for an open standard.
I would love to use weechat for Matrix, as I'm not a big fan of the Riot client.
How does that translate to superior communication between my coworkers and I? Most of that stuff does not matter to people.
But to answer your question, self-hosting would be useful in making sure that internal communication isn't shared with a third-party. e2e could also be useful (depending on what you work on) if you want to just use the public servers.
Not to mention that you can use Matrix like bog-standard instant messaging (replacing the need for other messaging applications through bridges), where those sorts of features are also useful.
But that's not the point you made. For it to be better in general, it has to improve the way people communicate.
I'm pretty sure it is the point I made when I said: "There are open protocols like Matrix which are superior to Slack". Maybe it was badly worded, but the original comment was talking about open protocols being not as good as Slack's protocol (which is why they have their own and aren't use open protocols). My response explained that there are open protocols that are better (in that they have more features), and that Slack not using them is not evidence that they aren't better (rather it's an indication that Slack won't give up the one thing it has full control over).
> For it to be better in general, it has to improve the way people communicate.
I'm not sure I agree that's the only requirement for something to be "better in general". You would probably agree with me that HTTPS is "better in general" than HTTP. Why? To users there is no practical difference other than it being more secure -- which you've ruled out as being something users care about.
Things can still be better while being transparent to most users, while the extra features are useful for a subset of users. Not every protocol improvement needs to revolutionise how people use a particular technology.
It does matter, you just haven't realized it yet.
I can think of a few features, in a few open protocols that started out as "open" but proprietary - https://en.wikipedia.org/wiki/XMLHttpRequest being the most well known.
> Stop complaining about companies not adopting open protocols and do something. Dominate the world using open protocols, then the walled garden companies will follow. It is not easy, it may even feel wrong, but it is the only way.
This, this is sage advice, this is what needs to happen, and we need to just take the time to do it. I am at the point where I think I'm ready to become a Stallman like zealot in my almost golden years.
TYL: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail and https://en.wikipedia.org/wiki/Pretty_Good_Privacy
I'd actually argue that email is one of the better systems, as I can manage and control my whitelist/blacklist myself. It makes things much more functional that way.
https://techcrunch.com/2016/03/24/email-is-dying-among-mobil...
And there's good reason for that. Email is basically the electronic equivalent of postal mail, a first pass at digital communication that aped the old medium. But the first email RFC was 35 years ago. MIME is more than 20 years old, and that's the last major capability improvement.
From the point of view of a teen who grew up on Facebook Messenger, Snapchat, Instagram, and Twitter, email is weird, old, and feature-deficient. They think of email in the way that I think of paper mail (mainly for formal and commercial use, not really for friends, somewhat quaint), or possibly how I think of a fax machine (quirky, obsolete, use only when forced).
We have been chatting since we have had networks. Believe me, e-mail is here to stay.
ducks
Nobody does, sadly.
Baking it into the protocol like Signal and WhatsApp did means nobody has to want it, they just get it included without having to bolt on any extras.
Another issue is that social platforms serve as a unique kind of directory service. It turns out that how good a chat system is at allowing you to find contacts to chat with might be just as important as how good it is at actually chatting with them.
One issue is adoption, but this is something that can be dealt with eventually.
How much I hate this "X is fragmented" argument. When two pieces of software that speak a common set of core protocols and thus can achieve at least some level of interoperability, but there is no perfect feature parity, then OH HORROR, IT IS FRAGMENTED!!1111 The obvious solution? Use a product that does not interoperate with absolutely anything at all ...
Next people are going to claim that you should learn some random endangered language instead of English to avoid the "fragmentation" due to the numerous dialects, I guess.
You mean use a product with a baseline feature set where you can count on all the clients seeing things the same way and supporting the same thing.
Have you tried using Psi (an XMPP client) to communicate with a user using the Slack client (well, after this change, obviously ...)? Did you have any success with that? No, of course not. In other words: Slack is obviously not a product where you can "count on all the clients seeing things the same way and supporting the same thing.". Slack works with exactly one client at the other end, so it is bullshit to claim that it "works the same with all clients", when in fact it works with exactly one client, and that's it, with other clients you get exactly no interoperability at all.
And it is bullshit squared to pretend that that is somehow an advantage over other technologies: No single client using any protocol provides an inconsistent featureset or interface. It doesn't matter which single client and which protocol you use, you will always get a consistent featureset and interface. That has absolutely nothing to do with Slack, but only with the fact that you standardize on one client.
A proprietary platform where everyone the same product with identical feature set would easy out-compete it. It is apparent that the cloud is obviously betting on the wrong horse.
IRC does have a lot of deficiencies, but they're well-understood and the client environment has adapted to them.
It's absolutely possible to provide all this in open protocols, and even in a reasonable timeframe.
Interestingly, I've felt the opposite way. Slack will often lose connection, fail to send messages, or fail to refresh and fetch new messages (ones I know exist, because I was sent a notification for them). IRC and XMPP don't seem to do this.
If we keep the attitude of "IRC solves all the problems it intends to solve," then the number of users whose problems are addressed by IRC shrinks more and more over time.
"All of this has happened before and will happen again."
I'm completely unsurprised. The integrations were there to reduce customer risk in choosing slack. Now that slack is big enough, they don't need to do that anymore. Those integrations can only let 3rd parties into the party that slack wants all for themselves.
Shit like this is why IRC is still so popular.
But, I've never used Slack nor would use it as I'm biased towards it's prop nature, especially when it's used (and even promoted) within open source communities.
Your time could be spent on open source, so don't claim that open source walked away from you, when you're the one doing it.
This is a server software issue, not a protocol issue.
Yeah, no. The email/xmpp approach of small core + extensions is probably the only viable way.
I've played with both rocket.chat and matrix - and while I don't really like the architecture of the former, it feel a lot more like a finished solution/product - with a sane api.
I hope Matrix will become more relevant, but I think the documentation and implementation suffers under the design ambitions.
In a certain sense smtp, imap and irc all use telnet for transport (and all can be augmented with ssl/tls). That's not a great choice today - but there seems to an odd resistance to combining "the good pieces we have". Maybe just demanding ssh as the (client/server) transport, for example. Use srv records for discovery. Use capnproto for serialization. I don't know, but there seems like there's and odd resistance to reusing great components that are easily tested and developed independently.
In that sense the slack/rocket mission is easier: be compatible with yourself.
(and using https+json for transport / rpc is perfectly valid re-use. But a promise for stable apis and a clear split between client and server (rather than client+server | bots (ie: non-Roman clients) would be nice. Allow people to bring their own server, or client or both.
>and there must be tons of marketing to promote it.
It used to be “build it and they will come”. Open source projects don’t have millions to spend on marketing.
This is what I mean by "it may feel wrong". We developers like to buy into this fantasy of "build it and they will come" but it has never been true.
[1] as specified somewhere here https://ircv3.net/
The only reasons I could see someone choosing not to use it are:
- Doesn't have the same plethora of plugins that Slack does, although it does have a fairly complete API.
- It is a gaming product and it shows, which might make some more straight-laced people balk at its perceived unprofessionalism.
https://discordapp.com/nitro
They are pretty open that they collect a lot of data about you, and this is not even the full list ("not limited to").
"...we may conduct research on our customer demographics, interests and behavior based on the information collected. This research may be compiled and analyzed on an aggregate basis, and we may share this aggregate data with our affiliates, agents and business partners"
Shared for dollars, of course.
"As we develop our business, we might sell or buy businesses or assets. In the event of a corporate sale, merger, reorganization, bankruptcy, dissolution or similar event, your information may be part of the transferred assets."
They can sell your data, including all the chats they have collected.
It is of course a Privacy Policy and not a Business Model strategy document, but it is pretty far-reaching and allows for monetization of anything you do with Discord. You are the product.
https://media.8ch.net/file_dl/25ece2fb253fc4e6cdd3ac4ed99e4f...
That means they may ban accounts for using it.
https://imgur.com/a/f2fuO
I don't believe anyone's written a fully-functional XMPP connector yet though.
Any combination of Hangouts, Skype, GroupMe, Telegram, and Gitter is free to connect.
We also had a Freenode BridgeBot, but couldn't get around the max connections per user issue.
The overwhelming majority of customers connect to Slack though, so it wouldn’t matter price-wise.
I think I’m the only one reading #stripe from Skype :-)
[1]: https://github.com/42wim/matterbridge [2]: https://matrix.org/
Have you tried running your own home server and then bridging your irc network to it?
It's not simple.
Note that unlike IRC, where bots or users must be on the same server rooms are completely independent of any single homeserver. There's nothing that says a room belongs to a certain homeserver. So the bridges set up by matrix.org will work with any room, unless you explicitly turn off federation.
I read https://medium.com/@RiotChat/slack-bridge-improvements-44c52...
I don't see a way to "add a slack" in Riot.
Slack is not standard. There is a lot of the things that can be better in many ways.