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

231–240 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#231

Post by scrollaway »

haroldp wrote: post #217
scrollaway wrote: post #143

Earlier quoted context omitted.

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

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

Re: Open Sourcers Race to Build Better Versions of Slack

#232

Post by scrollaway »

FireBeyond wrote: post #208
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/

IRCv3 has been around since 2004 and seems like it has largely failed to gain any traction, even among IRC networks - why would that change now?

The ircv3.net organization and the movement behind it started in 2012 and gained traction in 2014-2015. You're thinking of something else.

Re: Open Sourcers Race to Build Better Versions of Slack

#233

Post by e12e »

ex3ndr wrote: post #83
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…

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.

Thank you for mentioning actor - I must have missed it the last time various open (federated) solutions were discussed.

It looks like an interesting platform, but I was a bit surprised by what I found at:

https://developer.actor.im/docs/encryption

"MTProto v2 Rev3 enables encryption support to replace or enchanse TLS one." So far so good - here's someone that's built on top of NaCl and built a legacy-free encryption system on top of well tested, known primitives, I thought.

But: "Actor encrypts message with US encryption and then again encrypt with Russian encryption that in result guarantee absolute encryption streight" (sic).

Uh. This sounds like applying a "political" reasoning to layering security: AES might be backdoored by NSA, GOST(?) might be backdoored by the FSB -- but using both, only double-agents will be able to foil our encryption!

While the truth is probably that you're know vulnerable to buffer overflows or other more mundane software errors in the now double-sized encryption code -- and get none of the (potential) benefits of a clean, modern architecture on top of just NaCl?

In addition, it appears you also use curve25591, possibly an implementation derived from NaCl:

https://developer.actor.im/docs/securing-server

"For secure communications Actor Server have to be configured with Curve25519 keys. To generate them, use actor-cli util:"

So that's three codebases worth of bugs, rather than one. Any plan to simplify this part?

Re: Open Sourcers Race to Build Better Versions of Slack

#234

Post by caf »

scrollaway wrote: post #231
haroldp wrote: post #217

Earlier quoted context omitted.

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?

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

Offline messages is a server issue, though - in principle there's no reason why you couldn't have a server that remembers offline messages and passes them to the client when it reconnects, framing them as regular IRC messages.

Re: Open Sourcers Race to Build Better Versions of Slack

#235

Post by Arathorn »

lewisl9029 wrote: post #222
ar0 wrote: post #211

Earlier quoted context omitted.

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

Not sure if any were mentioned in the piece, but there are plenty of zero knowledge E2E encrypted chat clients out there. None of the ones I'm aware of are also federated like Matrix is though, and I suspect the federated nature of Matrix probably makes E2E encryption a lot more complicated to implement than I can ever imagine. I definitely appreciate that the Matrix team is aware of and actively working on E2E encry…

Agreed that E2E is mandatory for privacy. The federated nature of Matrix doesn't make it any harder to implement though - after all, TextSecure/Signal has basic federation too. The one subtlety we have is that we want to give the users the option of selecting between PFS and replayable epochs of history on a per-room basis - the latter making it easier to sync history between devices; the former being for the privacy paranoid.

Now, a more interesting privacy concern is that Matrix doesn't and can't protect metadata currently - see https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E... for details. So if you want both encrypted contents as well as obfuscated metadata, go check out Ricochet or Vuvuzela or Pond or something for now :)

Re: Open Sourcers Race to Build Better Versions of Slack

#236

Post by coroutines »

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…

As someone somewhat related to an IRC project, it's frustrating talking to people who love Slack because most of what they want is something that would be supported in an IRC client - not the IRC protocol.

Semi-related:

IRCv3 is an advance in the right direction, but I wish they would make huge breaking changes now - instead of introducing new standards to manage a migration to "later IRC".

Two things I want to see are IRC encoded as JSON, and TLS-only servers in the standard as a requirement. They added message tags which I think just makes IRC ridiculous to parse - if the objective is to extend IRC and add ancillary data to the message they should just use JSON already. I think it's a bad move to allow some intermittent migration path if we all know the end-game is IRC encoded as JSON. It'd be dirt-simple to autodetect if you're receiving JSON or traditional IRC, too. You don't need a CAP exchange to tell you "oh look, it's gonna be fucking json, m8".

An example a feature IRC would need to change for is the ability to edit messages. Slack lets you go back and correct already-submitted messages. You don't have this ability in IRC - and there are ethical reasons to not support it. Personally I'd be in favor of IRC having a command for editing messages, and then clients keeping the entire history of edited messages - so you can always see the original. It's not like the server can take that data back - it's jsut assumed clients would show only the latest, revised version of a message.

I could also see having the IRC server support a virtual DCC user to upload files to - so then you could emulate file attachments like you have on Slack. This is something that can be abused though - file uploads are a security and DoS concern. Slack can support certain things because the infrastructure is paid for - with IRC networks it's largely a "free" operation.

In the past I've made a "Hookbot" that triggers and POSTs to outside services just like Slack. On some IRC networks there are network-vetted bots you can request in your channel to configure and make use of. You can largely support everything Slack does in existing IRC, we just needs standards to add some coherency and expectations for developers/users.

UX does matter, I completely agree with you - IRC needs to change minimally to support those Slack-like features, though. Clients need to change. Most of the draw of Slack is embedding linked items in the chat for convenient viewing. Even icky Mibbit does that :p

Re: Open Sourcers Race to Build Better Versions of Slack

#237

Post by kccqzy »

oblio wrote: post #137
wlesieutre wrote: post #126

Earlier quoted context omitted.

Yes, the check boxes are a bug in HipChat. That's part of my point: I have literally never seen a native OS X application that couldn't lay out checkboxes properly. Working in html/electron opens you up to making these UI bugs a lot more easily than native development.

That's the risk of customizing the UI in any cross platform toolkit. I'd rather have slightly wonky cross platform apps than native apps for a very limited subset of platforms.

I think transmission did the right thing: a single core shared across all platforms, tailored UI for different platforms. And yes, the existence of a web app makes it available absolutely everywhere, and the existence of fully native UIs make it a joy to use.

EDIT: spelling

Re: Open Sourcers Race to Build Better Versions of Slack

#238

Post by wslh »

I think the Achilles heel of almost every open source projects is [end-]user experience. The first time I used Slack I was sure it was trivial to replicate the software (not the business) by a small team of developers but a short time after I realized a lot of UX details that a normal open source team will not prioritize ever (e.g. conversationally educating the user about new features).

Probably the weakest point of Slack is their price. A similar open source SaaS offering will not be free so Slack has margin to compete.

Re: Open Sourcers Race to Build Better Versions of Slack

#239

Post by seivan »

rekoros wrote: post #147
scrollaway wrote: post #138

Earlier quoted context omitted.

Ok. It's kind of good to hear the barrier to open sourcing is more legal than commercial. That means it's fixable :) Can I ask you some details on how you went about working with Skype and Hangouts? Did you do the reverse engineering yourself? These are protocols several popular open source projects have been trying to support for years and haven't succeeded. Can I also ask you about your tech stack/languages you use…

We implemented them ourselves, and it took quite a bit of work. Our magic weapon is Erlang, which is a wonderful language for working with protocols, and a wonderful runtime for working with many things happening at the same time. The other magic weapons are the Cowboy webserver and the Gun http client -- both written by Loïc Hoguin. Loïc doesn't work for us, but we've been sponsoring him financially for over two yea…

Care to share your webpack config for getting React and TypeScript to play ball? I'm collecting a bunch to try to figure out what works best.

Re: Open Sourcers Race to Build Better Versions of Slack

#240

Post by quadrangle »

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.

Sounds like you just need the AGPL
Post reply on HN