Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

Post reply on HN
Print view View original

141–150 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#141

Post by vvanders »

rekoros wrote: post #127
scrollaway wrote: post #119

Earlier quoted context omitted.

Thank you, that PDF is incredibly depressing. By the way, well done on sameroom. I came across your product while working on the stuff I mentioned and it looks like an incredibly useful thing. I really wish you would open source it, though. (Or at least open source some libraries for talking to the protocols you deal with. Especially Hangouts.)

Thank you! We're so paranoid about getting shut down by Google (Hangouts, no API), Microsoft (Skype, no API), and Facebook (Messenger, no API) that we're not only not open sourcing any of our implementations, we're not even providing a commercial API in fear of having to deal with some form of abuse. That said, the night is young. We hope to eventually gain enough leverage to get the big guys to listen to us.

Reminds me of the story around AIM/MSN wars from back in the day.

http://www.theverge.com/2014/4/21/5635488/msn-messenger-vs-a...

https://nplusonemag.com/issue-19/essays/chat-wars/

Re: Open Sourcers Race to Build Better Versions of Slack

#142

Post by maaku »

dandelany wrote: post #125
scrollaway wrote: post #78

A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up. Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts? Some sort of open protocol. Urgh, I've been…

You're certainly right that the UX of most IRC clients is seriously lacking compared to eg. Slack. But one thing I've always wondered - is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps? There's no reason why the protocol itself has to handle UX features like emoji/embedding/etc. - just send a text token over the wire and have the client interpret it as a specially di…

These services are really replacements for IRC bouncers, which are not as well standardized (but should be).

Re: Open Sourcers Race to Build Better Versions of Slack

#143

Post by scrollaway »

dandelany wrote: post #125
scrollaway wrote: post #78

A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up. Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts? Some sort of open protocol. Urgh, I've been…

You're certainly right that the UX of most IRC clients is seriously lacking compared to eg. Slack. But one thing I've always wondered - is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps? There's no reason why the protocol itself has to handle UX features like emoji/embedding/etc. - just send a text token over the wire and have the client interpret it as a specially di…

> is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps

The IRC protocol is old. It predates HTTP. Some things are possible in theory, but pointless if no client supports them.

Look into ircv3 (http://ircv3.net/), they're writing new specs for the IRC protocol to build exactly what you're talking about. It's very promising, although IMHO too little, too late - Matrix looks like it's going to take the crown eventually.

Re: Open Sourcers Race to Build Better Versions of Slack

#144

Post by andrey_utkin »

scrollaway wrote: post #130
andrey_utkin wrote: post #110

Earlier quoted context omitted.

> We need open protocols. You have that - SIP and XMPP. Please don't complain that they are complex and consist of a lot of documents, and have hard feature standartization path. It is the only possible way to openly evolve such systems - to publish serious writeups as documents on their own and have them discussed with criticism and then gradually adopted. And then you may end up with competing alternative implement…

The specs are not directly the problem in XMPP. They just amplify it. The real issue is XMPP does not directly solve the problems the authors of those chat apps deal with. Doing things properly requires writing XEPs and just a lot of hassle which a company building its own little Slack killer doesn't want to invest in, and doesn't have a reason to invest in either because none of the current ones support XMPP in the…

> XMPP does not directly solve the problems the authors of those chat apps deal with

Could you please recap which problems exactly? I though the problems which matter nowadays is independence from vendors, and, after that, reuse of existing software.

> Doing things properly requires writing XEPs and just a lot of hassle which a company building its own little Slack killer doesn't want to invest in

So they don't. But I think it's obvious that the point of current discussion is that owned networks are no more satisfactory because of lack of openness and freedom. XEPs and IETF RFCs are exactly for this purpose, so they are necessary.

> If you want to fix this, you have to do that work for them.

For whom "them"? Vendors of yet another IM service? I don't need any of them.

> You have to make XMPP a direct solution that says "Spin up this server, write a cool UI, and your product is done".

It is pretty much so nowadays. You would be surprised how many commercial messaging systems run XMPP software internally, and how much building up the solution is close to what you've said.

Re: Open Sourcers Race to Build Better Versions of Slack

#145

Post by cyphar »

rekoros wrote: post #132
brazeon wrote: post #116

Earlier quoted context omitted.

Do you plan on open sourcing plugs or any parts of your system?

You can see what happens to OS projects that work with WhatsApp, Skype, and some of the other heavily guarded walled gardens -- cease & desist orders, carried out by GitHub. We have absolutely no interest in joining that list, which unfortunately means the answer - for the time being - is no :(

Right, but surely if you're selling it that's much more incentive for a cease and a desist (regardless of whether it is free software).

Re: Open Sourcers Race to Build Better Versions of Slack

#147

Post by rekoros »

scrollaway wrote: post #138
rekoros wrote: post #127

Earlier quoted context omitted.

Thank you! We're so paranoid about getting shut down by Google (Hangouts, no API), Microsoft (Skype, no API), and Facebook (Messenger, no API) that we're not only not open sourcing any of our implementations, we're not even providing a commercial API in fear of having to deal with some form of abuse. That said, the night is young. We hope to eventually gain enough leverage to get the big guys to listen to us.

Ok. It's kind of good to hear the barrier to open sourcing is more legal than commercial. That means it's fixable :) Can I ask you some details on how you went about working with Skype and Hangouts? Did you do the reverse engineering yourself? These are protocols several popular open source projects have been trying to support for years and haven't succeeded. Can I also ask you about your tech stack/languages you use…

We implemented them ourselves, and it took quite a bit of work.

Our magic weapon is Erlang, which is a wonderful language for working with protocols, and a wonderful runtime for working with many things happening at the same time.

The other magic weapons are the Cowboy webserver and the Gun http client -- both written by Loïc Hoguin. Loïc doesn't work for us, but we've been sponsoring him financially for over two years (https://medium.com/@abs/what-we-learned-from-sponsoring-an-o...).

Our frontend doesn't really matter as much, since it's just a dashboard, but we use TypeScript with Flux and React (it's been great).

Re: Open Sourcers Race to Build Better Versions of Slack

#149

Post by SwellJoe »

beyti wrote: post #120

adblock blocker on wired, so upset

I don't mind them, normally, but in the case of Wired their detection is broken for uBlock. It continues to detect the blocker as on, even once disabled. So, reading Wired is now impossible for me, even if I accept their ads (which, I tend to be fine with for companies I trust not to be too invasive, and not to have ads that make noise or start video without warning).

Re: Open Sourcers Race to Build Better Versions of Slack

#150

Post by kitsunesoba »

benologist wrote: post #22
wlesieutre wrote: post #15

Earlier quoted context omitted.

Mattermost claims to have "Native Applications". ( http://www.mattermost.org/community-applications/#native ) Turns out they mean "electron is a native application, and our app is a webpage inside of electron, so our webpage is a native application." Bummer. I use both Slack and Hipchat for different groups, and I'm not happy with the wrapped webapp for either of them.

What's wrong with that? VSCode is also such a thing, high performance and beautiful apps are obviously possible.

Apps built with front end web tech are nearly always heavier than their fully native counterparts, for one. It's nothing for an electron-based app to gobble up 150MB, 250MB, and higher amounts of memory while doing (in terms of resources actually required for the given task) nothing. A great comparison is Sublime Text, which takes up ~35MB of memory at cold start, even with a few plugins enabled. Compare this to VS Code or Atom, which take around 200MB right out of the box. That's downright comical, and I can't accept the "but resources are cheap" excuse. That mentality has been robbing users of the lightning-fast, ultra-silky experiences that are possible even on decade-old hardware for years now and it needs to stop.

Aside from that, non-native applications inevitably introduce accessibility issues and UX incongruencies with the rest of the system that are difficult if not impossible to resolve entirely. There's a huge trade off made when using web tech for desktop applications and developers would do well to deeply consider their choice of technologies before acting.

Post reply on HN