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

331–340 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#331

Post by teekert »

zanny wrote: post #298
takeda wrote: post #268

Earlier quoted context omitted.

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.

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.

Re: Open Sourcers Race to Build Better Versions of Slack

#332

Post by creshal »

leonroy wrote: post #197
creshal wrote: post #188

Earlier quoted context omitted.

All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.

btw. very much agree most of the clients are inadequate but if I could humbly pimp Openfire (I'm a dev there): https://github.com/igniterealtime/Openfire And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd You'll see that on the server side at least XMPP is very well catered for.

I've used both and moved on to prosody. Ejabberd is just too arcane to configure and debug; and openfire is a damn resource hog for no apparent reasons.

Re: Open Sourcers Race to Build Better Versions of Slack

#333

Post by khc »

pyre wrote: post #189
vvanders wrote: post #141

Earlier quoted context omitted.

Reminds me of the story around AIM/MSN wars from back in the day. http://www.theverge.com/2014/4/21/5635488/msn-messenger-vs-a... https://nplusonemag.com/issue-19/essays/chat-wars/

Or how AOL's Oscar protocol got updated at one point to start requesting chunks of the AOL IM binary as authentication against open sources clients (because they couldn't distribute AOL's binary with their client).

Do you have a source for this?

Re: Open Sourcers Race to Build Better Versions of Slack

#334

Post by creshal »

txdv wrote: post #325
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…

How have you implemented skype? Have you written a stand alone library which communicates with skype?

Skype has a web-based API nowadays that's used by quite a few third-party clients.

Re: Open Sourcers Race to Build Better Versions of Slack

#335

Post by zamalek »

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…

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.

Re: Open Sourcers Race to Build Better Versions of Slack

#336

Post by tveita »

groovy2shoes wrote: post #82
lotyrin wrote: post #60

Earlier quoted context omitted.

It's easier to host (at least on the scale that most teams would, few nodes, few tens of users, no need for services -- basically `apt-get install ircd-of-choice`) than to use, but I disagree that it's easy to use. I can tell anyone in any kind of role (senior to junior, technical to non-technical) on my team to "Download (the/a) client for X and join #channel #channel2" "Follow the directions to set it up so changes…

Are you fucking kidding me? I've been using IRC since I was 10. If a 10-year-old can figure it out, I think a professional engineer can figure it out. Using your typical IRC client to join a channel is just 4 steps: 1. Download IRC client. 2. Pick a nickname. 3. Pick a server. 4. Join a channel. With something like kiwiirc, you can even omit steps 1, 3, and 4: you can give someone a URL to a particular channel on a p…

Yeah, we tried that. You forgot setting up TLS, authentication, and oh you wanted a backlog? You'll have to switch to this different client that runs in the cloud / on a Linux server.

If there were no other alternatives we could probably manage somehow, but there's much less friction in "here's the URL, sign up with your email address"

Re: Open Sourcers Race to Build Better Versions of Slack

#337

Post by pjc50 »

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…

GTalk did, but as soon as they became popular they intentionally broke it

This is the thing. If nobody owns it, nobody can exploit it; if nobody can exploit it, it can't get VC funding.

Re: Open Sourcers Race to Build Better Versions of Slack

#338

Post by _pmf_ »

Too bad Google insisted on dead-birthing Wave by throttling access via beta invitations.

It generated incredible hype, but a lot of people (including me) could not use it due to this bullshit; maybe they can acquire Slack and reengineer it using the much more mature Wave foundation.

Re: Open Sourcers Race to Build Better Versions of Slack

#339

Post by edhelas »

andrey_utkin wrote: post #94
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…

> 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 that we have now all the tools to build a decentralized, standard and universal IM (and also social !) network without reinventing the wheel again and again.

You can have a look at our latest release-note as well https://pod.movim.eu/?node/pubsub.movim.eu/Movim/f5f883e3122... (this blog post has been published/edited using Movim and XMPP ;)).

And Movim is also compatible with Spectrum to offer interconnection with other networks ;)

Re: Open Sourcers Race to Build Better Versions of Slack

#340

Post by ex3ndr »

e12e wrote: post #233
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.

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 implementation can contain bugs, yes, but i can guarantee that there are no timing or overflow attacks possible. Even when we will have broken russian layer, us layer will be safe. Also we are on the way to make everything verified by 3rd parties and seal cryptography parts.

For key exchange we use curve25519. Implementation is taken directly from Signal and this app is trusted by majority.

We

Post reply on HN