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.
The web (and web apps) are all about providing an experience. I don't want an experience, I want a reliable tool.
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.
(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'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?
Being “able-bodied” is only temporary, for everyone. Any dev that doesn’t realize this will eventually come to regret it as they age.
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.
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.
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.
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.
That's somewhat similar to how ed works. You choose a line number or range and print those lines to the screen.
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.
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.
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.
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.
I mean that might just be how you code, and GP does not code that way...
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.
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!)
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.
I don't know why I need to use slack [...] just
reinventing irc
* 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.
chances it will be around in 10 years? I would say 25%.
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'.
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.
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.
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.
> 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.
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.
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 [email protected] 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.
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.
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.
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.
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.
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.
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.
Baffling that so many people still use it as yet another mode of transportation.
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!
Can't wait to use the term "AIMd" on "Slack" (what a stupid name BTW) in 10 years.
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.
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?
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!"
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.
[1]: https://matrix.org/docs/projects/client/quaternion.html
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.
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.
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.
https://accessibility.blog.gov.uk/2016/11/01/results-of-the-...
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.
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.
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.
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.
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.
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.
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.
On X, this means emacs-slack displays images, emoji &c. just like the web or pseudo-native clients do.
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.
Standalone client and its helpers are sitting on ~800MB committed on my install of High Sierra. Might be worth a shot.
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.
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.
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.
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.
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.
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!
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.
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.
On a side note, Last Chance to See is a great book (Douglas Adams) and show (Stephen Fry), highly recommend both of them.
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.
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.
It's only ~100 KB(!)
It will be out of alpha this month.
"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."
> What language is eul written in?
> C. There's also some Objective-C for macOS UI.
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.
For now you can run it from Terminal.
https://twitter.com/harisamin/status/727634194814373889
I've posted about it before here on HN but wasn't sure if there's enough interest
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.)
> 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.