Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

271–280 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#271
post #268

Earlier quoted context omitted.

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…

This is so disappointing. Especially Jabber/XMPP was created to fix that issue by standardizing the protocol. The idea is that IM would be like email - no central server. Others (GTalk, Facebook, WhatsApp, HipChat to name few) started implementing it but did not enable server to server communication (ok GTalk did, but as soon as they became popular they intentionally broke it with Hangouts). So now we have bunch of s…

I think because it's a "nice-to-have", not a "must-have".

(We have SMTP, a must-have.)

There is no such thing as a "nice-to-have" universal protocol.

Re: Open Sourcers Race to Build Better Versions of Slack

#272
post #199

Earlier quoted context omitted.

Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue. XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.

> chat archiving for example This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.

Sounds like XMPP isn't the solution then, only {???,XMPP} is.

Re: Open Sourcers Race to Build Better Versions of Slack

#273

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…

As it turns out, the tower of Babel is completely self-perpetuating.

Re: Open Sourcers Race to Build Better Versions of Slack

#274

Hopefully Mattermost and Rocket.Chat both build mature, robust HA systems since their features [honestly] are on par with Slack. Then move into SaaS hosting of their service in VM clusters across ~3 regions. :) Really, the only thing that stops me from wanting to use these services at $DayJob is the fact I have enough stuff I have to maintain. I'd really rather just pay $99/month for a 10-20 person team.

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.

Re: Open Sourcers Race to Build Better Versions of Slack

#275
post #218
post #76

Earlier quoted context omitted.

I honestly don't get this. I've been using IRC for a few years, but I don't think nearly enough for blind eye nostalgia to take hold. It's not like you're stuck with ugly terminal only clients anymore. There is KiwiIRC, IRCCloud, and several other great web clients that not only let you connect to any server but provide bouncer services and backlog. There are also plenty of easy to use native clients that don't requi…

I don't want "backlog" (read: see what happened when I was gone). I want full-text searching of the entire channel history. I already log my IRC conversations, and it's a pain in the goddamned ass to ssh to my bouncer, grep through the logs, and try to find what I was looking for. I want to type in the same client that I'm chatting in, and be able to reference this message to other people. IRC doesn't do that.

grep works way better than Slack's search, which makes you wait several seconds per tiny page of search results. I look forward to the day when Slack catches up to grep.

Re: Open Sourcers Race to Build Better Versions of Slack

#276

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.

Have you implemented the IRC protocol? It's horrible.

Re: Open Sourcers Race to Build Better Versions of Slack

#277

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…

Note that rocket chat can federate [1] over matrix [2], and I believe mattermost can as well.

[1] https://matrix.org/docs/projects/as/rocket-chat-federation.h... [2] https://matrix.org

Re: Open Sourcers Race to Build Better Versions of Slack

#278

Earlier quoted context omitted.

> Professional Engineer Yeah, here's where you fucked up reading my post. > anyone in any kind of role (senior to junior, technical to non-technical) I'm talking about Joe Frontend, Billy Design Intern, Gary Office Assistant. Maybe you work on teams that are 100% neckbeards that aren't afraid to crack open an RFC to get daily shit done (and waste huge amounts of company resources on things that should be simple), but…

I've never needed to open an SSH tunnel to connect to IRC. I click on the Xchat icon, and two seconds later I'm connected. I don't know where you're getting these ideas that using IRC requires consulting the RFC or opening SSH tunnels, because you don't need to do either of those things.

Plain and simple: If IRC was easy enough for joe in marketing and steve in sales to use, they'd be using it years ago.

Re: Open Sourcers Race to Build Better Versions of Slack

#279

Earlier quoted context omitted.

You mean the same IRC that doesn't include basic features like the ability to receive messages if you aren't currently connected? The same IRC that has horrible scaling issues once you try to really use it? The same IRC that is a miserable experience to setup, administer, search, and even use? Stop touting IRC as the "perfect" chat system. It's far from it.

Traditionally offline message caching would be the responsibility of a bouncer, or something like memoserv. There is an interest to make this responsibility part of the server in IRCv3, though. IRC scales much, much better than Slack. Unreal or InspIRCd or Charybdis whatever - Slack fails miserably for hundreds of thousands of users in one "team"/network. I do agree administering/configuring IRC servers has to get ni…

99.9% of Slack users don't give a shit about hundreds of thousands of users in on network. Slack scales better than IRC at anything other than absurd rates.

Re: Open Sourcers Race to Build Better Versions of Slack

#280
post #61

If someone want performance, simplicity and encryption, take a look at our project: https://actor.im

The download page lists "Mac OSX, Linux x86", Linux x64, Windows x86, Windows x64". The average user does not know what x86 or x64 means, and if they assume that the larger number is the latest (because duh) then they'll be causing problems down the line by installing the 32bit version on their (probably 64bit) machines.

Traditionally, this is solved by autodetecting their OS and giving them a big link in giant UX-ey button form as "recommended", and only mentioning the other platform links in smaller letters below that.

So, I don't think it's quite ready for grandmas yet.

Post reply on HN