Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

131–140 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#132

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…

Do you plan on open sourcing plugs or any parts of your system?

You can see what happens to OS projects that work with WhatsApp, Skype, and some of the other heavily guarded walled gardens -- cease & desist orders, carried out by GitHub.

We have absolutely no interest in joining that list, which unfortunately means the answer - for the time being - is no :(

Re: Open Sourcers Race to Build Better Versions of Slack

#133

This is one of those applications that is always being rewritten somewhere. JWZ's law may even be relevant here: "Every program expands until it reads mail". It seems there is always a large group people out there working on messengers. The question really is what made Slack special. Why is it the Slack revolution and not the HipChat revolution? What about the veneer has allowed it to become a pervasive trend, expand…

It could've been the HipChat revolution. It was so close to being just that. As a user of both HipChat and Slack, however, the difference is vast. Slack had a rich API an integrations well before HipChat did; presents rich content substantially more attractively; had first-class mobile support off the bat; tracks unread messages when you're offline (this one is extremely frustrating in HipChat); made being a member of multiple teams simple; had a much smoother signup process... etc.

The organisation I work for got on board the HipChat train just as Slack was gaining momentum. While it's cheaper, I think if we'd had Slack we'd have much greater adoption.

Re: Open Sourcers Race to Build Better Versions of Slack

#134

Earlier quoted context omitted.

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.

Completely tangential but if you use quassel, check this little thing I built for a channel we own:

https://github.com/jleclanche/quassel-weblog

There's a demo in the URL field (not hotlinking here directly because it's a weak server). I didn't really document it but there's backlog search, ?highlight= functionality and it's straightforward to add functionality.

Re: Open Sourcers Race to Build Better Versions of Slack

#135

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…

Out of curiosity: are you leveraging such software as spectrum (spectrum.im) and libpurple? These pieces seem to be a good fit for internal gears of your product.

Good luck, you are working on an important problem.

Re: Open Sourcers Race to Build Better Versions of Slack

#136

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 di…

It has DCC protocol built in, but it isn't nearly as robust as most would like for it to be.

Re: Open Sourcers Race to Build Better Versions of Slack

#137
post #123

Earlier quoted context omitted.

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.

That's the risk of customizing the UI in any cross platform toolkit. I'd rather have slightly wonky cross platform apps than native apps for a very limited subset of platforms.

Re: Open Sourcers Race to Build Better Versions of Slack

#138

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

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.

Ok. It's kind of good to hear the barrier to open sourcing is more legal than commercial. That means it's fixable :)

Can I ask you some details on how you went about working with Skype and Hangouts? Did you do the reverse engineering yourself? These are protocols several popular open source projects have been trying to support for years and haven't succeeded.

Can I also ask you about your tech stack/languages you used for Sameroom?

Re: Open Sourcers Race to Build Better Versions of Slack

#139

Earlier quoted context omitted.

Slack is IRC, it just is a really nice interface that makes it easy to automate and makes it easy to share files/code/etc.

That's Slack's main feature. Well that and gifs. IRC on the other hand is James has left the channel. Bill has left the channel. Samantha has joined the channel. Samantha has left the channel. filled with worthless status updates Martha has gone idle that make it Bill has joined the channel. terribly easy to Bill has changed the channel topic to "ZOMG! Ponies!" miss things Martha has become active Martha has left the…

You can turn all of those notices off; I've not seen those sorts of updates in channel for years & years.

Re: Open Sourcers Race to Build Better Versions of Slack

#140
post #123

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN