Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

311–320 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#311

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…

Here's a timeline we put together of about 60 incompatible chat services: https://cdn.sameroom.io/chat-timeline.pdf Our service Sameroom ( https://sameroom.io ) is a commercial solution to the chat incompatibility disaster, not too different from an AC adapter thingy with a bunch of different plugs, one or two per continent. After implementing the protocols of quite a number of these systems (~20), we're seeing a sca…

you left out ICB

Re: Open Sourcers Race to Build Better Versions of Slack

#312

Earlier quoted context omitted.

No amount of markdown makes up for the lack of offline messages.

We already have offline messages, it's called email. "Oh, Johnson isn't online? better send him an email. /message acmebot email johnson@acme-supply.co Get your ass to mars!" chat bot sees the command and sends him the email. Sorry if I'm coming off as cynical it's just that I see a trend of the entire community trying to fix problems that aren't real problems.

Chat is not e-mail. It's chat. It has a much different feel to it. One brings a different mental context to e-mail than they do to chat. It is accessed differently, and the use patterns are very different. Hence, solving "offline chat" by sending an e-mail... this is not a real solution.

You could argue that some of the characteristics we find in chat are not useful, counter productive, etc. And there is probably some truth to that. But that is a different argument than what you made.

Re: Open Sourcers Race to Build Better Versions of Slack

#313
post #306

Earlier quoted context omitted.

You find yourself in the same position that Trillian did, what, 15 years ago? Thanks for giving it a shot, at least. It's getting to the point where if I wanted to keep in touch with most of my friends all the time, I'd need to carry two or more devices (thanks for keeping iMessage closed, Apple).

iMessage works fine with SMS and MMS.

Which is absolutely irrelevant. It's expected from a mobile phone to be able to send and receive SMSs. But SMSs can take several minutes to reach its destination in some areas. Long messages are split. And the experience as a whole is totally different. And of course, most people pay per message (individually or as a pack), at least globally. So, if someone wishes to send a message, it shouldn't matter what OS or app is being used by the other party. IF GP uses an Android phone as its primary phone, it may be problem if he is trying to chat with someone who uses only iMessage.

Re: Open Sourcers Race to Build Better Versions of Slack

#314

Earlier quoted context omitted.

No amount of markdown makes up for the lack of offline messages.

We already have offline messages, it's called email. "Oh, Johnson isn't online? better send him an email. /message acmebot email johnson@acme-supply.co Get your ass to mars!" chat bot sees the command and sends him the email. Sorry if I'm coming off as cynical it's just that I see a trend of the entire community trying to fix problems that aren't real problems.

That's not really a protocol level solution. Sure, it works, if you know how to do it - but you don't automatically gain that knowledge "out of the box", you have to learn it. It is a real problem to anyone trying it out that doesn't understand why they can't send a message to someone who is offline.

Re: Open Sourcers Race to Build Better Versions of Slack

#315
post #254

Earlier quoted context omitted.

There is, actually. IRC has no concept of timestamps. IRC has no concept of foreign metadata, even, so shoehorning isn't even possible without looking horrible. IRCv3 fixes all that.

Prefixing a date/timestamp unless the client has asked for IRCv3 timestamps is reasonable.

Yep. This is how slack does it, least for their xmpp gateway. I imagine that their irc gateway is similar.

Re: Open Sourcers Race to Build Better Versions of Slack

#316
post #288

Earlier quoted context omitted.

> Am I wrong? Yes and no. Setting up an IRC server is hard. Pretty much all IRC servers use arcane settings and configuration formats. I run an Inspircd and Hybrid servers, and for people who aren't used to it, it's really daunting compared to setting up something like prosody. Services on top like Kiwi are nice. I run Shout IRC which is beautiful and slack-like, but again requires passenger and node to work, so lots…

Yea. And isn't it funny though in an age of Docker and pre-made VMs that we still configure stuff? Seems like a quick script would set all this up for us :D

A lot of ircds disgustingly put some config options in at compile time, including things like the servername. A friend of mine had her irc server give the generic name for her ircd for several months because she couldn't be arsed to spend the time to recompile and reconfigure.

Re: Open Sourcers Race to Build Better Versions of Slack

#317
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).

Wired is 80% garbage articles and intrusive ads / trackers these days. I don't recommend it.

Re: Open Sourcers Race to Build Better Versions of Slack

#318

This is why I sort of hate open source. Slack is doing a great job, their prices are right. So why is it OK to destroy that? With what is going to be not as good stuff? I'll get down voted to hell but come on. It's cheap, it's good, so why not let the guy make a living? And for the record I don't even know who the guy is (or woman is). I just hate the "it's cool, lets rip it off attitude". Because the ripoff is rarel…

How is open source 'destroying' anything? Last I heard Microsoft was considering buying Slack for billions of dollars. I don't think they're destroyed.

In fact, I'd consider any open source alternatives to Slack to be fair game on an open market, and the massive underdog at this point.

Re: Open Sourcers Race to Build Better Versions of Slack

#319

Earlier quoted context omitted.

I set up rocket chat on my home server as a test and it's been great. I use it to chat with my family. So far the maintenance has been very minimal.

I deal with production stuff at my $DAYJOB and it needs to run for 6+ months without a single on-call event for me to consider it minimal.

I've had zero problems with the server (like memory leaks or random crashing), but the iOS app started complaining when the server was roughly 3 months out of date. To stop the errors there I had to upgrade the server code (which was itself pretty simple). That doesn't meet your criteria, but I've find it pretty minimal by my standards.

Re: Open Sourcers Race to Build Better Versions of Slack

#320

Oh man this entire field is madness... especially when you realize this when trying to get ahold of someone: I'll try Slack... let me check Skype... no maybe they're on HipChat... SMS... oh hell I'll just call them!

Yes it is fairly ridiculous. Which is why an open protocol / non-closed environment would help solve this.

Yeah, IRC is from the 80s and is lacking some modern features, but at least it was a fairly unifying chat system in its day. No one company owned it, most people could use it trivially, and there were many different clients out there to suite one's taste.

There's still a market for wrapping a protocol in a nice web app UI and hiding the complexities from the user, which is why this closed chat systems trend is getting frustrating.

Can't different chat services communicate with each other easily, without the need for a bridge?

Post reply on HN