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

291–300 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#291

Post by mmel »

luckydude wrote: post #242

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…

Do you really hate open source? or is that just an exaggeration? I find it hard to believe anyone could actually hate open source.

Re: Open Sourcers Race to Build Better Versions of Slack

#292

Post by _nfin »

soared wrote: post #279
coroutines wrote: post #258

Earlier quoted context omitted.

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.

I don't understand your point - Slack can't scale for extremely large teams well. I've watched the desktop and web app grind to a halt on the first load of a channel because it's still loading in channel history/offline messages. Beyond that, when trying to tab-complete a nickname this similarly almost freezes the desktop app. This has been my experience as part of a team on Slack that has 4000+ users. These are client-side problems, really - but I don't see how you can say Slack scales better when all of its [great] features come at a cost that limit how large a team can be. The larger the team, the more noticeable it becomes.

The history should load in progressively as needed. Switching channels within the same team should be instant. I don't know how you fail at tab-completing nicknames and commands, but somehow they made that slow. I get the feeling rendering is not on a separate thread in the desktop app.

Anyway, you're right that not everyone needs to be on 7-9 networks with the ability to talk to everyone among those. Slack is great for teams of like 500 people and less (imo).

Re: Open Sourcers Race to Build Better Versions of Slack

#293

Post by zanny »

lewisl9029 wrote: post #216
Arathorn wrote: post #121

Earlier quoted context omitted.

Matrix signs all of its messages to avoid homeserver providers tampering with message history. Actual encryption however requires E2E encryption, which is in the wings via our "Olm" Axolotl implementation ( http://matrix.org/git/olm ). Progress can be tracked at https://matrix.org/jira/browse/SPEC-162 . So I don't think you should reject Matrix on trust issues quite yet (although if you're really worried you should c…

Glad to see there's been progress on this front! The lack of E2E encryption is literally the last thing holding me back from building apps with Matrix. Can't wait to give it a try! =)

Axolotl has a well defined message structure using established crypto functions. All of them, for example, except Curve25519 are in Crypto++. You can probably fairly easily bake your own, albeit I'd use the olm from Matrix and just make theirs work well first.

Re: Open Sourcers Race to Build Better Versions of Slack

#294

Post by bphogan »

_b8r0 wrote: post #288
bphogan wrote: post #281

Earlier quoted context omitted.

Edit: looks like someone asked a similar question below. I'm curious though. What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings. I use a nice web gateway (kiwi) on top of an IRC…

> 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

Re: Open Sourcers Race to Build Better Versions of Slack

#295

Post by bphogan »

foolfoolz wrote: post #284
bphogan wrote: post #281

Earlier quoted context omitted.

Edit: looks like someone asked a similar question below. I'm curious though. What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings. I use a nice web gateway (kiwi) on top of an IRC…

i think the #1 value add from slack/hipchat is that it's hosted for you. we spend thousands of man-hours each month and year keeping our servers up. uptime is hard. chat is not hard. historical chat is not hard. when chat is down, your business is at risk. there's other services at my company we pay for that aren't very complicated - we just don't want to host it. paying $5/user/mo for chat that is always up is easie…

Makes sense.

Although I take issue with "when chat is down your business is at risk."

Pick up a phone. Use Skype. Send email.

Business was done for thousands of years before chat apps. :D

Re: Open Sourcers Race to Build Better Versions of Slack

#296

Post by zanny »

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.

There are actually FOSS implementations of Hangouts wrappers (Hangups) Skype wrappers (SkypeWeb for libpurple) and Facebook wrappers (purple-facebook) and even a telepathy wrapper for the Facebook protocol.

Nobody is getting sued yet, and Pidgin supports all of them nowadays.

Re: Open Sourcers Race to Build Better Versions of Slack

#297

Post by fweespee_ch »

__david__ wrote: post #274
fweespee_ch wrote: post #12

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.

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.

Re: Open Sourcers Race to Build Better Versions of Slack

#298

Post by zanny »

takeda wrote: post #268
rekoros wrote: post #107

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…

People do care. I'm working on a Qt Matrix client for KDE / maybe eventually Telepathy.

The problem is non-techies do not understand why email is good while messaging is bad. There is no indication as to where these problems would come from, and they have no insight into why the problem happens in the first place, while they gleefully eat up iMessage / Facebook Messenger / Skype / Hangouts / Whatsapp.

Re: Open Sourcers Race to Build Better Versions of Slack

#299

Post by zanny »

fiatjaf wrote: post #175
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…

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

I wrote a Matrix client library in Qt about three weeks ago, and it was really braindead simple.

JSON in, JSON out. HTTP codes tell you what response you got. TLS on an https connection for secure communications. WebRTC for voice calls, and you just query the API for the signaling server to use.

Re: Open Sourcers Race to Build Better Versions of Slack

#300

Post by zanny »

Arathorn wrote: post #128
manav wrote: post #75

Earlier quoted context omitted.

There's also Matrix.org. There seems to be a lot of overlap between the two projects.

Matrix is very different to IRCv3 actually - you can think of Matrix more as a openly federated object database with pubsub semantics and a standard HTTP API. One use happens to be group chat, others include WebRTC signalling, IOT data exchange, etc. Meanwhile IRCv3 is very much an evolution of classic IRC - it's still closed federation, uses the IRC line protocol, and is all about group chat. We're looking forward t…

I for one welcome our Matrix overlords, where all our communication needs are done over HTTP json requests, and you can have interop servers into every other network through federated gateways.

Honestly, it is the future. Everything except Ring / Tox* should just pack up and start contributing to Matrix :p

* Because there is still use for anonymous fully peer to peer messaging, but the marginal utility IMO does not outweigh the incredible tradeoffs you have to make to implement it for normal people (ie, no history, the need to pass around account tokens between devices, slowish message propagation).

Post reply on HN