Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

361–370 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#361

Earlier quoted context omitted.

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

That works less well if, for some reason, your business is significantly built around chat (Live Chat for sales, for example). It's perfectly possible to pivot your sales funnel, but it's not something you can do in two hours whilst the chat server's down.

So you plan for it. We just had this whole discussion on HN a few weeks ago when Mandrill changed and everyone was scrambling.

If you rely on a third party for business, you need to plan for it.

The rule always applies: You will pay now or you will pay later.

Re: Open Sourcers Race to Build Better Versions of Slack

#362

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…

If you opened your chat, you would be losing the capacity to own the people in your chat and thus never get fidelization (or monetization). Think of a bar that lets you bring drinks from other bars. It doesnt have good prospects.

Imagine that. All the money TBL could have made had he kept the web closed.

Re: Open Sourcers Race to Build Better Versions of Slack

#363

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…

People want to make money, pretty straightforward. If I build something closed and people adopt it, I might get acquired!

Re: Open Sourcers Race to Build Better Versions of Slack

#364
post #298

Earlier quoted context omitted.

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.

Because to a non-techy, running a messaging server is just as out of reach as running a mail server. It's just too difficult.

Lots easier than before. Off the top of my head: 1: You have more than enough 'power users' who keep their machines on 24/7 for torrent seeding. VirtualBox is free & those guys are fairly security conscious as a result of the inherent defensive nature of torrenting (MPAA litigation, etc). Give them a VBox server they can run and they'd happily do it. Now grandma can use his server no problem, in the same way that you only needed 1 techie in your group (pre-AOL) to host an SMTP server.

The real difficulty is convincing grandma that she needs to leave "AOL".

Re: Open Sourcers Race to Build Better Versions of Slack

#365

Earlier quoted context omitted.

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.

Couldn't you just make sure that puppet/chef/whatever runs the right config options? Maybe a script that asks you for values up front and plugs them in?

Re: Open Sourcers Race to Build Better Versions of Slack

#366
post #346

Earlier quoted context omitted.

> And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…). Can you recommend a few? I haven't looked into XMPP in detail for a while, because the clients I've been using are "good enough and I didn't bother with mobile), but it seem…

Well I can recommend Conversations for Android https://play.google.com/store/apps/details?id=eu.siacs.conve... which have some really nice features and is fitting well with Movim. For the desktop there is no real "modern" client yet, unfortunately. But I've ported Movim using Electron :) There is already a Ubuntu/Debian version and the package is here https://github.com/edhelas/movim_electron .

For desktop, I've heard of Adium for Mac. For Linux, the one with most decent features support is Gajim, but it is far from being perfect.

Re: Open Sourcers Race to Build Better Versions of Slack

#367

Earlier quoted context omitted.

The problem is that the IM protocol space seems very opinionated. "XMPP? XML sucks!" "Web sockets? Web sockets suck!" "JSON? JSON sucks!" "Binary? That prevents telnet, binary sucks!" People do care, it just seems as though they care about their pet peeves more.

That "XML" sucks thing is why we don't have single-sign on (YuBiKey is doing a great job getting half way there though). We keep on reinventing the wheel re: authorization & authentication despite the fact that there are well-defined, cryptographicly secure[0]. SAML2[1] has been standardized, implemented, operates in a similar fashion to SMTP/Kerberos (i.e., your identity is established (i.e. authentication) purely t…

We integrate pretty deeply with SAML and, yes, it's awesome tech. It makes complete sense that XML was used because real namespaces are important for claim extensibility. Sadly, "XML sucks!"

Re: Open Sourcers Race to Build Better Versions of Slack

#368
post #340
post #233

Earlier quoted context omitted.

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…

Our encryption is based on Java and everywhere we check buffer overflows and possible timing-attacks. Hopefully we use AES and SHA256 that is easy to validate. Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform. US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementatio…

You're not helping your case. You make it sound like you are using bricks without knowing what their strength is.

It's a bit like saying you made a boat out of wood for buoyancy and filled it with sand in case the wood catches fire. Sure, a plank of wood doesn't sink, but too much sand can make it sink, and sand won't be of much help if there is a fire. A wooden boat is better than one filled with sand.

I'm not sure how the fact that the boat was made in Java is relevant, either. If anything, it makes it harder to prove that there is no timing attack, as the JIT could do unexpected things, long after the program has started.

Re: Open Sourcers Race to Build Better Versions of Slack

#369

Earlier quoted context omitted.

Thanks for the insight. It reflects what I often hear from other people close to XMPP. What are your thoughts on Matrix?

Looks like they're making all the right noises in order to be a viable successor to XMPP. Really does look good, but seems to be in its very early stages. Reminds me of what the Layer guys were trying to do (at least in their initial mission statement). https://layer.com Pros of Matrix are that it looks like they have full chat support, are working on adding end to end encryption, and of course have federation which…

There are quite a few large/huge companies building stuff on Matrix - looking at the copyright statements of the code in github.com/matrix-org reveals a few. Many of them are using it in commercial stuff which hasn't launched yet - and meanwhile Matrix is still in beta, so understandably they don't publicise their activity too loudly about their activity atm.

In terms of resources: a bunch of us are paid by our dayjobs to work on Matrix fulltime, and meanwhile there's a pretty active wider community surrounding the project. However, the 'core' project of building a spec, reference server, reference+glossy web and native ios/android clients, as well as loads of bridges really is a significant amount of work, and we're going as fast as we can. https://www.openhub.net/p/matrixdotorg gives an idea of progress (although only seems to spider a few of the core projects). I wouldn't really call Matrix a 'small' project :)

In an ideal world we'd stop the world and take N months to entirely rewrite Synapse (~40KLOC of rather dense Python/Twisted) to Go/Rust/C++/Java/Node/whatever, but that's N months we don't have right now. It's not really the lack of resource, but the fact that the window is rapidly closing to provide an interoperable fabric between all of these proprietary communication apps (be they open source or commercial licensed), and we want to get a stable solution out there before it's too late and we end up in a world where the silos have won (c.f. social networks).

Hence the pragmatic decision to do an incremental migration from Synapse to Dendron, which is our next-gen homeserver written in Go (not C). Dendron is indeed mainly 'just' a proxy for now, but this is actually incredibly cool as it can act as a Matrix-aware loadbalancer across multiple Synapse backends. The horizontal scalability and HA this gives is a huge deal. Meanwhile, it gives us a way to gradually migrate endpoints from Synapse into Dendron and provide a way to replace the Synapse codebase without having to do a stop-the-world rewrite. Personally, I think this pragmatism is ftw.

In terms of verbs in URIs... we've been pragmatic rather than religious about REST naming conventions; if someone can give concrete reasons to rename endpoints before we freeze the spec, please tell us! Bugs to http://matrix.org/jira/browse/SPEC and PRs to http://github.com/matrix-org/matrix-doc please ;)

And whatever, please do come hang out on #matrix:matrix.org and #matrix-dev:matrix.org eitherway if you want to find out more and help us escape beta!

Re: Open Sourcers Race to Build Better Versions of Slack

#370

Earlier quoted context omitted.

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…

Have you heard much about the Signal server federation? It's been more than a year since it was mentioned (that I've seen) by the Open Whisper Systems folks. I'm hoping it's still on some sort of roadmap.

I'm not sure it's a huge priority there currently, but we don't have any internal knowledge. We asked to federate Signal with Matrix (which is a concrete possibility given we share the same E2E spec) and were politely turned down, as they'd prefer Signal to be a silo whose security they control rather than risking interop with 3rd parties. Hopefully they will change their mind in future once Matrix's E2E is more proven :)
Post reply on HN