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

121–130 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#121

Post by Arathorn »

lewisl9029 wrote: post #103
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.

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…

Matrix signs all of its messages to avoid homeserver providers tampering with message history. Actual encryption however requires E2E encryption, which is in the wings via our "Olm" Axolotl implementation (http://matrix.org/git/olm). Progress can be tracked at https://matrix.org/jira/browse/SPEC-162. So I don't think you should reject Matrix on trust issues quite yet (although if you're really worried you should certainly wait for E2E to land).

Re: Open Sourcers Race to Build Better Versions of Slack

#122

Post by ne0phyte »

scrollaway wrote: post #93
91bananas wrote: post #90

Earlier quoted context omitted.

Doesn't it also lack a common, arguably nice, frontend? With integrations to everything under the sun pre-built, requiring no management by the implementers? Built in bouncers, searchable history, etc?

A frontend is actually the one thing it's not lacking. IRCCloud.com supports ircv3 and is a very nice "slacky" UI to IRC.

Sadly IRCCloud is still lacking one 100% crucial feature: a backlog search. I've been a paying IRCCloud user for almost 2 years now and back then they already had the search feature on the roadmap as "coming soon". The only way right now is to keep scrolling and scrolling and then some more scrolling until you find what you are looking for. In a busy channel this is pretty much pointless.

Re: Open Sourcers Race to Build Better Versions of Slack

#123

Post by oblio »

wlesieutre wrote: post #79
benologist wrote: post #22

Earlier quoted context omitted.

What's wrong with that? VSCode is also such a thing, high performance and beautiful apps are obviously possible.

That's true, but when you roll a "one size fits all" HTML app across all platforms, it's much much less likely to follow operating system conventions and very easy to get layout details wrong. For example, Hipchat's settings overlay ( https://i.imgur.com/V3UOyMI.png ) which should: • Be a separate window • Be sized properly for its contents instead of having to scroll • Use tabs along the top for the settings categor…

Aren't most of those application bugs? For example, I don't see why the check boxes should be clipped in any web application, since in their default configuration (no CSS), they aren't. So the Hipchat CSS borked the default widget.

Re: Open Sourcers Race to Build Better Versions of Slack

#124

Post by [deleted] »

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…

[deleted]

Re: Open Sourcers Race to Build Better Versions of Slack

#125

Post by dandelany »

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…

You're certainly right that the UX of most IRC clients is seriously lacking compared to eg. Slack. But one thing I've always wondered - is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps? There's no reason why the protocol itself has to handle UX features like emoji/embedding/etc. - just send a text token over the wire and have the client interpret it as a specially displayed element. The only thing it may not handle well is file uploads... but even then, I seem to recall IRC having built-in support for sending files?

Re: Open Sourcers Race to Build Better Versions of Slack

#126

Post by wlesieutre »

oblio wrote: post #123
wlesieutre wrote: post #79

Earlier quoted context omitted.

That's true, but when you roll a "one size fits all" HTML app across all platforms, it's much much less likely to follow operating system conventions and very easy to get layout details wrong. For example, Hipchat's settings overlay ( https://i.imgur.com/V3UOyMI.png ) which should: • Be a separate window • Be sized properly for its contents instead of having to scroll • Use tabs along the top for the settings categor…

Aren't most of those application bugs? For example, I don't see why the check boxes should be clipped in any web application, since in their default configuration (no CSS), they aren't. So the Hipchat CSS borked the default widget.

Yes, the check boxes are a bug in HipChat. That's part of my point: I have literally never seen a native OS X application that couldn't lay out checkboxes properly. Working in html/electron opens you up to making these UI bugs a lot more easily than native development.

Re: Open Sourcers Race to Build Better Versions of Slack

#127

Post by rekoros »

scrollaway wrote: post #119
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…

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

Thank you!

We're so paranoid about getting shut down by Google (Hangouts, no API), Microsoft (Skype, no API), and Facebook (Messenger, no API) that we're not only not open sourcing any of our implementations, we're not even providing a commercial API in fear of having to deal with some form of abuse.

That said, the night is young. We hope to eventually gain enough leverage to get the big guys to listen to us.

Re: Open Sourcers Race to Build Better Versions of Slack

#128

Post by Arathorn »

manav wrote: post #75
navait wrote: post #36

For talking about a race, Wired seems to have neglected a crucial technology: ircv3[1]. I'm not very fond of IRCv2, and have moved away from it where I previously used IRC. But IRC is popular, has a lot of clients, and v3 has a lot of promise. Why didn't the author bother to mention it? [1]: http://ircv3.net/

There's also Matrix.org. There seems to be a lot of overlap between the two projects.

Matrix is very different to IRCv3 actually - you can think of Matrix more as a openly federated object database with pubsub semantics and a standard HTTP API. One use happens to be group chat, others include WebRTC signalling, IOT data exchange, etc. Meanwhile IRCv3 is very much an evolution of classic IRC - it's still closed federation, uses the IRC line protocol, and is all about group chat. We're looking forward to bridging it into Matrix :)

Re: Open Sourcers Race to Build Better Versions of Slack

#129

Post by dorfsmay »

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

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.

There's been some effort towards integration between SIP and XMPP:

https://tools.ietf.org/html/rfc7247

Re: Open Sourcers Race to Build Better Versions of Slack

#130

Post by scrollaway »

andrey_utkin wrote: post #110
tambourine_man wrote: post #62

We need open protocols. Then let a thousand clients with different paradigms bloom

> We need open protocols. You have that - SIP and XMPP. Please don't complain that they are complex and consist of a lot of documents, and have hard feature standartization path. It is the only possible way to openly evolve such systems - to publish serious writeups as documents on their own and have them discussed with criticism and then gradually adopted. And then you may end up with competing alternative implement…

The specs are not directly the problem in XMPP. They just amplify it.

The real issue is XMPP does not directly solve the problems the authors of those chat apps deal with. 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, and doesn't have a reason to invest in either because none of the current ones support XMPP in the first place (the bootstrap problem).

If you want to fix this, you have to do that work for them. You have to make XMPP a direct solution that says "Spin up this server, write a cool UI, and your product is done".

Post reply on HN