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

211–220 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#211

Post by ar0 »

lewisl9029 wrote: post #103
ex3ndr wrote: post #83

Earlier quoted context omitted.

We are actually trying to make open protocol in https://actor.im with federation with https://matrix.org . It seems that only Actor and Matrix understand importance of federation.

I haven't looked into actor much yet, but the last time I looked at Matrix, my main concern was how much implicit trust users needed to place in homeserver providers (messages and user profiles are stored in plaintext). Unless this has changed, I don't find it viable for any app that values user privacy. Even federated networks eventually gravitate towards a large degree of centralization once the tech becomes mainst…

But isn't the same true for Slack and its "open source competitors" mentioned in the Wired peace?

At least that's how I read Slack's security page (https://slack.com/security-practices) that only talks about "Data Encryption In-Transit" (i.e. server-to-client) and Mattermost's About page (https://about.mattermost.com/) that also talks (only) about encrypted "client-server data transmission".

I do agree that end-to-end encryption is important, but at least Matrix is aware of this and they are working on it (https://matrix.org/jira/browse/SPEC-162).

Re: Open Sourcers Race to Build Better Versions of Slack

#212

Post by donatj »

rekoros wrote: post #107
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…

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…

The timeline is missing the fact that ICQ converted to Oscar after the AOL acquisition and users on both networks can talk.

Re: Open Sourcers Race to Build Better Versions of Slack

#213

Post by jlgaddis »

klint wrote: post #183
navait wrote: post #36

For talking about a race, Wired seems to have neglected a crucial technology: ircv3[1]. I'm not very fond of IRCv2, and have moved away from it where I previously used IRC. But IRC is popular, has a lot of clients, and v3 has a lot of promise. Why didn't the author bother to mention it? [1]: http://ircv3.net/

Hi, I wrote the Wired article in question. I hadn't heard about IRCv3, but it does sound like it would plug some of the holes in IRC that Slack users complain about. It wouldn't really have been a good fit for this article, since I was mostly focused on the two Slack-alikes with most traction, at least according to Black Duck's data (an imperfect measure to be sure) and IRCv3. As for why I didn't mention IRC in gener…

Yet, in the open-source world, IRC is one of the primary mediums for community support and developer collaboration.

Re: Open Sourcers Race to Build Better Versions of Slack

#214

Post by adrianpike »

55acdda48ab5 wrote: post #207
adrianpike wrote: post #205

Earlier quoted context omitted.

They're all different when it comes to communication bandwidth and effectiveness. We need to discuss something visual as a five-person team? A phone conference is the wrong medium. We need to collaborate on a significant technical document? Slack is the wrong medium. We need to have a searchable back-and-forth discussion, interleaved with other things that are vying for our attention? We should probably use a chat to…

> We need to have a searchable back-and-forth discussion, interleaved with other things that are vying for our attention? This is email. > We need to discuss something visual as a five-person team? A phone conference is the wrong medium. Shared desktop conference, such as gotomeeting.

If those work for you and your team, that's great!

However, the growing number and popularity of alternatives should be a strong signal that they do not work for every team.

Re: Open Sourcers Race to Build Better Versions of Slack

#215

Post by [deleted] »

55acdda48ab5 wrote: post #207
adrianpike wrote: post #205

Earlier quoted context omitted.

They're all different when it comes to communication bandwidth and effectiveness. We need to discuss something visual as a five-person team? A phone conference is the wrong medium. We need to collaborate on a significant technical document? Slack is the wrong medium. We need to have a searchable back-and-forth discussion, interleaved with other things that are vying for our attention? We should probably use a chat to…

> We need to have a searchable back-and-forth discussion, interleaved with other things that are vying for our attention? This is email. > We need to discuss something visual as a five-person team? A phone conference is the wrong medium. Shared desktop conference, such as gotomeeting.

[deleted]

Re: Open Sourcers Race to Build Better Versions of Slack

#216

Post by lewisl9029 »

Arathorn wrote: post #121
lewisl9029 wrote: post #103

Earlier quoted context omitted.

I haven't looked into actor much yet, but the last time I looked at Matrix, my main concern was how much implicit trust users needed to place in homeserver providers (messages and user profiles are stored in plaintext). Unless this has changed, I don't find it viable for any app that values user privacy. Even federated networks eventually gravitate towards a large degree of centralization once the tech becomes mainst…

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! =)

Re: Open Sourcers Race to Build Better Versions of Slack

#217

Post by haroldp »

scrollaway wrote: post #143
dandelany wrote: post #125

Earlier quoted context omitted.

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 lo…

I'm sure that I'm over simplifying, but can't you just put tokens or markdown right in the chat for those sort of things?

If you have an old, flat IRC client, it's ugly but you can figure it out. If you have a supported client you get a nice UI?

Re: Open Sourcers Race to Build Better Versions of Slack

#218

Post by op00to »

chc4 wrote: post #76
matthewmacleod wrote: post #14

Earlier quoted context omitted.

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 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.

Re: Open Sourcers Race to Build Better Versions of Slack

#219

Post by ne0phyte »

ubernostrum wrote: post #106
minitech wrote: post #96

Earlier quoted context omitted.

> Follow the directions to set it up so changes on this Trello board are posted to #channel

Yeah, nobody's ever written things that can respond to events by posting messages in an IRC channel. Shame, really.

Actually I know several IRC channels that have bots that send messages for activity on GitHub, Twitter, etc. And writing IRC bots is among the easiest things ever. The IRC protocol isn't hard and there are lots of libraries, snippets and bots out there.

Re: Open Sourcers Race to Build Better Versions of Slack

#220

Post by rekoros »

peteretep wrote: post #209
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…

It doesn't look like you provide quite what I'm after, which is a single OS X / iOS app that seamlessly connects to all of those, while supporting the differentiating features of each. Would easily shell out $30 for such a thing, and maybe even $10 a month for a licensed version. Setting up "tunnels" between client installs probably gets me fired.

We focus on connecting teams vs individual productivity. Check out http://meetfranz.com/ for a single app option.

About getting fired - not if we sell our solution to your IT :) They might like it, actually, since they can a) provide something useful to their user base and b) get a better handle on the chat situation.

Post reply on HN