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

341–350 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#341

Post by kyberias »

imglorp wrote: post #77
andrey_utkin wrote: post #41

What about reusing and polishing XMPP and existing decent software for it? About donating money to people who develop it all these years? No, we'll spread FUD upon XMPP or just ignore it but will proceed to use and abuse its legacy behind the closed doors. http://risovach.ru/upload/2016/03/mem/novyy--shablon_1085837...

For one thing, XMPP is complicated and difficult to implement.

This may be the primary reason for the multitude of protocols. Everyone thinks every existing protocol is complicated and thinks that they can implement it better. Or: https://xkcd.com/927/

Re: Open Sourcers Race to Build Better Versions of Slack

#342

Post by thenomad »

bphogan wrote: post #295
foolfoolz wrote: post #284

Earlier quoted context omitted.

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

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.

Re: Open Sourcers Race to Build Better Versions of Slack

#343

Post by amai »

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…

I think Signal from https://whispersystems.org/ deserves to be mentioned, too.

Re: Open Sourcers Race to Build Better Versions of Slack

#344

Post by andrey_utkin »

brongondwana wrote: post #263
andrey_utkin wrote: post #144

Earlier quoted context omitted.

> XMPP does not directly solve the problems the authors of those chat apps deal with Could you please recap which problems exactly? I though the problems which matter nowadays is independence from vendors, and, after that, reuse of existing software. > Doing things properly requires writing XEPs and just a lot of hassle which a company building its own little Slack killer doesn't want to invest in So they don't. But…

battery life / fast reconnection (aka, the mobile problem) push notifications "message was only sent to my other client and I didn't see it" (dunno if this is solved now, was a problem when I last used XMPP in anger) scrollback / history search editable messages embeddable rich content reliable interop (aka: my mental model of how a message I create will appear to my viewers doesn't need me to understand 100 differen…

> battery life / fast reconnection (aka, the mobile problem)

Don't see what to reply here

> push notifications

Solved https://github.com/siacs/Conversations#how-do-xep-0357-push-...

> "message was only sent to my other client and I didn't see it"

Message Carbons XEP-0280, implemented mostly everywhere (except Pidgin)

> scrollback

Message Archive Mgmt, server-stored chat history (this + carbons gives you chat sync on par with skype).

> history search

Client app matters. I don't see this function in Conversations (Android), but it is in Gajim and Mcabber, to mention few.

> editable messages

Sure, XEP-0308. E.g. Gajim enables you to do that. Ctrl+UpArrow and you are editing it, then your conversation/groupchat peers see it edited.

> embeddable rich content

Images and markup? Sure. Don't know about GIFs, well, maybe that's why Slack took off - better support for GIFs.

> reliable interop

I think this is not quite fair complaint towards software ecosystem which is currently mostly not supported financially. Indeed, this is quite the problem keeping XMPP and mere mortals apart, but XMPP is closer to reliable interop than yet-another-new-slack-killer-company or NIH-driven-community-project. Keep in mind huge variety of existing software and amount of problems resolved. Let's stand on shoulders of giants, not on the mere ground.

> my mental model of how a message I create will appear to my viewers doesn't need me to understand 100 different clients and their quirks

Not an XMPP problem. In open world, you are safe to assume variety, not sameness. I love my scriptable terminal-based chat client, are you going to deny me in having one? I want a text-to-speech generator to read your messages to me, and free protocol enables me to do that, is your mental model of your message disrupted? I want to have your message translated by some engine and presented in different language, is your mental model of your message disrupted? Or, I am blind and I use Braille terminals, are you going to deny me in using it?

Re: Open Sourcers Race to Build Better Versions of Slack

#345

Post by e12e »

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

Ok. But why use AES and GOST? AFAIK they're both based on feistel networks? If one were to layer two symmetric encryption schemes today I'd think one would go with something like salsa[ed:chacha] and keccak (in authenticated encryption mode) -- and it would probably still be a bad idea, adding much more complexity than security?

[ed: Oh, and here I go, proving that non-cryptographer should be careful about what they say wrt encryption, apparently AES isn't a feistel cipher? http://crypto.stackexchange.com/questions/10605/why-is-aes-n... ]

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

It's a pretty strong claim to say that you take three different encryption primitives, implemented by other people in java, and translate them to other languages -- and can also be sure there are no timing attacks? (Or oracles, or resulting errors)?

Surely it would be easier to stick to as few lines and layers as possible if you want it to be easy(er) to audit?

(So simple there's obviously no mistakes, vs so complex there's no obvious mistakes and all that).

Re: Open Sourcers Race to Build Better Versions of Slack

#346

Post by detaro »

edhelas wrote: post #339
andrey_utkin wrote: post #94

Earlier quoted context omitted.

> open source multi-protocol group chat gateway What about Spectrum http://spectrum.im/ ? I am successfully using Spectrum as gateway to Skype (except groupchats ATM, some bugfixing pending) and IRC from my XMPP client apps. What about XMPP in the whole? It looked depressing few years ago, but times have changed, I can help you to catch up with nice novelties.

XMPP has changed yes. 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…). I'm personally working on Movim, a nice-looking "Social-IM" client fully based on XMPP ( https://movim.eu/ ). The main goal of the project is to show tha…

> 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 seems like I'm missing out on good things ;)

Re: Open Sourcers Race to Build Better Versions of Slack

#347

Post by conanbatt »

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…

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.

Re: Open Sourcers Race to Build Better Versions of Slack

#348

Post by Spakman »

Arathorn wrote: post #235
lewisl9029 wrote: post #222

Earlier quoted context omitted.

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…

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.

Re: Open Sourcers Race to Build Better Versions of Slack

#349

Post by qznc »

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…

I might be alone here, but I don't see the problem. I also do not believe that federation or interop would be a good feature for group chats.

You want to pick and choose your UI? That is an anti-feature. One user sends an image and the other cannot display it because he uses a terminal client. One user sends an emoji, another client only displays a box, because he has no glyph in his font. This is already a problem with XMPP. It has lots of nice features, but each requires server and client to support it. There is no "Full XMPP" label.

And since you prominently talk about the protocol: XMPP probably has all the features one needs. Why hasn't it won yet? Because the complexity of all server-client combinations makes a good user experience too hard.

What is the problem with using different clients/networks for different groups? Why do you want to mix work and private groups into the same app? What does matter (especially for web apps) is a unified authentication scheme (Mozilla Persona would be my favorite), so I can quickly switch between them and do not need lots of accounts. Thus: Federated accounts, but diverse chat solutions.

(disclaimer: I slightly exaggerated to play devil's advocate)

Re: Open Sourcers Race to Build Better Versions of Slack

#350

Post by bnj »

levemi wrote: post #20
tribaal wrote: post #2

If only there was a well supported, standard, open and interoperable text messaging protocol (with multiple implementations) that companies could host themselves... Oh wait, IRC.

Doesn't mention IRC, doesn't mention Discord. I'm suspicious that a PR firm pushed this to a journalist.

correct me if I'm wrong- Discord isn't open source (?)

Love Discord, wish it were, but I just did a quick check and couldn't find anything there

Post reply on HN