Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

171–180 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#171
post #99

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…

> Some sort of open protocol. XMPP seems to be rather dead, for various reasons, and no real contender for a replacement has sprung up. I guess there always is, and always will be IRC…

Its still widely used in large projects, but those projects normally modify the protocol to fit their needs (whatsapp, riot games)

Re: Open Sourcers Race to Build Better Versions of Slack

#172
post #77

What about reusing and polishing XMPP and existing decent software for it? About donating money to people who develop it all these years? No, we'll spread FUD upon XMPP or just ignore it but will proceed to use and abuse its legacy behind the closed doors. http://risovach.ru/upload/2016/03/mem/novyy--shablon_1085837...

For one thing, XMPP is complicated and difficult to implement.

It may look intimidating at first, but it's really very easy once you get the basics.

HTTP and IRC on the other hand look easy at first, then you get past that and there's just more and more complications and edge cases and horror. Like all the various cache headers and behaviors in HTTP, or how all IRC networks have their own dialect that's subtly different.

I once tried to work on an IRC server interface, I read all the RFCs, wrote code, then tested with a client. Nothing worked, so I had to resort to replay what the client sent to a different network and reproduce whatever they did.

If you go read the XMPP RFCs, you should be able to write a client or a server that gets along pretty well with the rest of the XMPP world.

Re: Open Sourcers Race to Build Better Versions of Slack

#173

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…

> A hundred different chat systems mentioned here. None of them compatible with one another.

Obligatory xkcd reference: ... ok, never mind, you probably all know which one I mean.

Re: Open Sourcers Race to Build Better Versions of Slack

#174
post #154
post #114

Earlier quoted context omitted.

If you're worried about the upvotes on the article, they're definitely legit (as far as we can tell). I suspect it's as simple as that Slack is a hot topic (for or against) and people here like open source. And are passionate about chat software.

Thanks dang!

Whoops, I did not mean to downvote you for this comment, I hit it when scrolling on my phone. Sorry

Re: Open Sourcers Race to Build Better Versions of Slack

#175

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…

It's easier to write your own protocol, that's the reason.

Laziness.

Re: Open Sourcers Race to Build Better Versions of Slack

#176

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…

The real problem is that the problem keeps changing. XMPP adapts. There's some friction. XEPs get written to deal with it. Life goes on. Someone invents yet another variation of IM and the cycle repeats.

Re: Open Sourcers Race to Build Better Versions of Slack

#177
What I conclude from this is that open-source developers are all hungry for good specs (for a killer application).

Therefore, wouldn't it be nice if there was a website where product designers (not software developers) could post their product designs, so that the developers have something to work from?

Re: Open Sourcers Race to Build Better Versions of Slack

#178
post #2

If only there was a well supported, standard, open and interoperable text messaging protocol (with multiple implementations) that companies could host themselves... Oh wait, IRC.

This comes up every time, and as usual you have totally missed the point . IRC is difficult to configure, difficult to host, difficult to use, and does not offer the same feature set as Slack. There is an obvious use case for something like Slack (obviously, because otherwise it would not have millions of users!) and covering one's ears while yelling "IRC! IRC! IRC!" is sort of wilfully ignoring that if it were a sui…

I think the point is that we should enhance IRC or XMPP, or create a new federated and open protocol that supports the features and easy setup Slack offers. Users suffer when we create proprietary protocols and walled gardens. Can you imagine if someone using Google Mail couldn't send an email to to someone using a university, government, or Yahoo email address? It would be unacceptable. However, this is the situation we are in with real time messaging protocols. It's infuriating to me that developers are content creating these systems. It's unethical, in my opinion.

Re: Open Sourcers Race to Build Better Versions of Slack

#179
post #165
post #99

Earlier quoted context omitted.

> Some sort of open protocol. XMPP seems to be rather dead, for various reasons, and no real contender for a replacement has sprung up. I guess there always is, and always will be IRC…

I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?

Google's abandonment of it was a big, big blow. 90% of my contacts are no longer available via XMPP.

Re: Open Sourcers Race to Build Better Versions of Slack

#180

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…

Also mobile notifications - that's a huge benefit of Slack and an IRC app couldn't (as far as I can see) provide them without maintaining a constant connection.
Post reply on HN