Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

301–310 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#301

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…

You find yourself in the same position that Trillian did, what, 15 years ago?

Thanks for giving it a shot, at least. It's getting to the point where if I wanted to keep in touch with most of my friends all the time, I'd need to carry two or more devices (thanks for keeping iMessage closed, Apple).

Re: Open Sourcers Race to Build Better Versions of Slack

#302

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…

re: Open Protocol, isn't XMPP a viable open source standard?

Re: Open Sourcers Race to Build Better Versions of Slack

#303

Earlier quoted context omitted.

I've never needed to open an SSH tunnel to connect to IRC. I click on the Xchat icon, and two seconds later I'm connected. I don't know where you're getting these ideas that using IRC requires consulting the RFC or opening SSH tunnels, because you don't need to do either of those things.

There's two ways this argument goes awry: "IRC is fine, you just have to be smart enough" and "Only ever use IRC for the things it does well", I thought we were on the other branch there for a bit. I had specifically included a scenario that is both common for use in my experience, and also pretty much impossible for a normal human using IRC in order to preempt this branch: > Follow the directions to set it up so cha…

Those are all good points (hell, I've been using IRC for nearly 17 years and I still don't know what half those flags mean). I think it's the first time I've seen a good argument about not using IRC!

I still think it'd be fairly easy to set up a company-internal server and make the whole process pretty streamlined for users. The only somewhat difficult part, then, would be the password. And I'm not sure how valuable message persistence really is, anyway, especially when you have your company email directory (and you could have IRC logs).

And for the record, I don't claim IRC's UX is without it's problems. It could certainly be improved a lot. I just don't think it's bad enough that people can't be expected to figure out how to log on and start chatting. At the same time, I think switching to a proprietary service that's run offsite is not a good solution. (We use XMPP where I work, but strangely not with conferencing. It works very well, but we're forced to use a shitty client (Cisco Jabber)). I've got high hopes that IRCv3 can start making improvements on a lot of the things you mentioned, but only time will tell.

Re: Open Sourcers Race to Build Better Versions of Slack

#304
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"?

> I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"? Well, it failed to be the preferred solution for its problem domain, and is universally ignored by big players. Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).

The thing is that Google moved from XMPP to something proprietary specifically to avoid federation. The big players don't want federation and any protocol will suffer the same fate unless it becomes popular without reliance on the big players. I think it is fair to say that XMPP isn't any more dead than any other protocol in this respect.

Re: Open Sourcers Race to Build Better Versions of Slack

#305
post #199

Earlier quoted context omitted.

> chat archiving for example This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.

Sounds like XMPP isn't the solution then, only {???,XMPP} is.

Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)

Re: Open Sourcers Race to Build Better Versions of Slack

#306

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…

You find yourself in the same position that Trillian did, what, 15 years ago? Thanks for giving it a shot, at least. It's getting to the point where if I wanted to keep in touch with most of my friends all the time, I'd need to carry two or more devices (thanks for keeping iMessage closed, Apple).

iMessage works fine with SMS and MMS.

Re: Open Sourcers Race to Build Better Versions of Slack

#307

Earlier quoted context omitted.

I find it interesting that all those who claim IRC is insufficient or is too hard to implement (they say the same about XMPP) don't ever seem to say what is so hard, or mention the features that are missing.

If you never read any comments that tell you what's so hard, then I guess you don't see them. To avoid repeating myself: http://lists.lca2016.linux.org.au/pipermail/chat/2016-Januar... As soon as you say "run a bouncer" you limit your audience severely. Without a bouncer, you're a transient in the world of IRC. Doubly so if you have the temerity to want to interact from a mobile device that pops on and off networks a…

I was in the LCA2016 IRC channel and at LCA2016 in person. I really wish we could have CCC [1] levels of "audience participation" because it allows people to interact with the conference who may not normally be able to attend. The live streaming was really well done but I think there needs to be One True Chat Channel for LCA2017. Maybe that means using Slack or similar and swallowing a bit of FOSS pride for a while.

[1]: https://events.ccc.de/congress/2015/wiki/Congress_Everywhere and yes, they use IRC. LCA's audience is a bit different

Re: Open Sourcers Race to Build Better Versions of Slack

#308

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…

Yes metadata is probably going to remain an unsolved problem for Matrix because it's not fully distributed, but I agree with the tradeoff Matrix is making here.

For now, building a great federated chat protocol that allows users to fully control their own data should take priority over just about everything else, because once users are in control of their own data, they're no longer locked to a single platform. So if another protocol comes along that does everything Matrix gets right and adds metadata protection, users can simply export their data and import it to the next great app/protocol (which is hopefully also federated). Until we have a great federated protocol that everybody is using, the friction associated with moving between chat apps/protocols is going to continuously inhibit real innovation in the messaging apps space by favoring apps that stand on the strength of their network effects over apps that stand on their own merits.

On the topic of fully distributed apps, I really like what replikativ is doing in this space:

https://github.com/replikativ/replikativ

It's a CRDT-based data replication library for building fully distributed applications. They envision replikativ being used as an open data exchange whereby users fully control their own data, and can specify any number of applications to have access to that data, instead of the status quo where user data is kept in closed, per-application silos. Their README has a much more comprehensive overview of the library and their vision.

Re: Open Sourcers Race to Build Better Versions of Slack

#309

Earlier quoted context omitted.

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

We already have offline messages, it's called email. "Oh, Johnson isn't online? better send him an email. /message acmebot email johnson@acme-supply.co Get your ass to mars!" chat bot sees the command and sends him the email. Sorry if I'm coming off as cynical it's just that I see a trend of the entire community trying to fix problems that aren't real problems.

Your "solution" does not work well with people on mobile. People on 2G/3G/LTE can alternate rapidly between online and offline. This kind of problem is easily solved by the chat server behaving like a store-and-forward device. Which is exactly what email is. But nobody likes to converse entirely using emails.

Chats have an important place because they allow us to say small things, quickly. What you suggest will result in no viable chat for mobiles, only emails. We can probably make a chat app that looks and feels like whatsapp but actually sends an email for every message. Dunno what problems this might have.

Re: Open Sourcers Race to Build Better Versions of Slack

#310
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"?

> I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"? Well, it failed to be the preferred solution for its problem domain, and is universally ignored by big players. Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).

> Well, it failed to be the preferred solution for its problem domain,

Google Talk, Facebook Chat, Origin (EA), Playstation, Cisco WebEx, WhatsApp all use/used XMPP for instant messaging.

That sounds like it's the preferred solution for realtime messaging, with vendor lock-in and NIH syndrome decisions being the major reasons that it isn't used in even more situations.

> and is universally ignored by big players.

As evidenced by the above list of major deployments, it is absolutely not "universally ignored". The problem (as someone else pointed out) is that for many of the "big players" a federated protocol is not what they want, so they don't allow federation, and don't allow/publicise the use of standard XMPP clients.

> Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).

This is a reason to stop using Google services, not a reason to claim XMPP is ill-suited to the task at hand.

Post reply on HN