Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

221–230 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#221
post #165

Earlier quoted context omitted.

I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?

Having used and developed with XMPP day in and out for the past 9 years I'd have to agree with the sentiments towards XMPP being on life support. It's a real damn shame because XMPP is pretty awesome. It's open for one, can be made super secure with OTR (client-2-client encrypted chats), has numerous protocols and implementations for stuff as diverse as message archiving, Audio/Video signalling, file transfer, chat (…

Thanks for the insight. It reflects what I often hear from other people close to XMPP.

What are your thoughts on Matrix?

Re: Open Sourcers Race to Build Better Versions of Slack

#222
post #211

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…

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 encryption, but it doesn't change my stance that Matrix is not a feasible building block for privacy-minded apps until that work is complete.

Re: Open Sourcers Race to Build Better Versions of Slack

#223

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.

What are the advantages of OpenFire over ejabberd/prosody?

Re: Open Sourcers Race to Build Better Versions of Slack

#224
post #212

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…

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

Thanks - will fix.

Re: Open Sourcers Race to Build Better Versions of Slack

#225

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…

> Some sort of open protocol.

https://en.wikipedia.org/wiki/Internet_Relay_Chat

https://en.wikipedia.org/wiki/XMPP

https://en.wikipedia.org/wiki/Session_Initiation_Protocol

Re: Open Sourcers Race to Build Better Versions of Slack

#226
post #164

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

Not sure what is so depressing here. According to the chart, a total of nine listed networks died in 50+ years, this is actually astoundingly low. And all IRC implementations are "interoperable" in the sense that a single client that implements the protocol can connect to any of them, this chart seems to be padding things a lot by calling every IRC server network a "chat service". A number of them also have or have h…

The depressing aspect is the accelerating fragmentation caused by more custom protocols entering the game. Supporting them all as the space grows will only get more cumbersome.

Re: Open Sourcers Race to Build Better Versions of Slack

#227
post #120

adblock blocker on wired, so upset

I don't mind them, normally, but in the case of Wired their detection is broken for uBlock. It continues to detect the blocker as on, even once disabled. So, reading Wired is now impossible for me, even if I accept their ads (which, I tend to be fine with for companies I trust not to be too invasive, and not to have ads that make noise or start video without warning).

Ghostery counts 27 trackers for me on this single Wired article, 19 of which are classified as "Advertising". I would not call this "not to be too invasive".

Re: Open Sourcers Race to Build Better Versions of Slack

#228

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…

> Some sort of open protocol. https://en.wikipedia.org/wiki/Internet_Relay_Chat https://en.wikipedia.org/wiki/XMPP https://en.wikipedia.org/wiki/Session_Initiation_Protocol

SIP is not am IM protocol. There's one crammed on top of it https://en.wikipedia.org/wiki/SIMPLE_%28instant_messaging_pr... but SIP is just a framing for it.

Re: Open Sourcers Race to Build Better Versions of Slack

#229
post #227

Earlier quoted context omitted.

I don't mind them, normally, but in the case of Wired their detection is broken for uBlock. It continues to detect the blocker as on, even once disabled. So, reading Wired is now impossible for me, even if I accept their ads (which, I tend to be fine with for companies I trust not to be too invasive, and not to have ads that make noise or start video without warning).

Ghostery counts 27 trackers for me on this single Wired article, 19 of which are classified as "Advertising". I would not call this "not to be too invasive".

I didn't look too deeply, but yeah, that's ridiculous. I don't need any Wired article that much.

Re: Open Sourcers Race to Build Better Versions of Slack

#230
post #111

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…

We have two options - end-to-end (experimental) and only client-to-server encryption. We are looking at ZeroDB to make it end-to-end by default and searchable. We had e2e default encryption but people start to scream after missing their phones and losing all theirs messages :( Also we had Tor-enabled client, but Tor is not suitable for mobile apps.

The possible integration with ZeroDB definitely sounds interesting! Really hoping that works out for you guys.
Post reply on HN