well, I do use it. That makes us two ;) I prefer grove over all other hosted chat services since it pretty much is IRC with archiving and "private". Works with any IRC client, so everyone can use the client he prefers - web, CLI, ... The protocol is simple and open and there's a ton of services that can actually integrate into IRC.
Yeah, I don't personally use Grove.io, I've just heard of it, but I am active daily on four or five different IRC networks (and tens of channels altogether).
Wait what? Have you been to any IRC channel in the last ten years?
IRC is a well-supported, still widely used, open standard for real-time communication. It can work just as fine on the browser with any of the hundreds of browser-based IRC clients. Heck, you could probably hook this Jabbr front-end to an IRC server without much pain.
Jabbr looks nice, but it's just a cute IRC reimplementation.
Let's not go overboard; chat interfaces have looked very similar to this in the past, but it's so easy to tweak the CSS to make it look different enough that not doing so is pretty lazy and makes it obvious who they're trying to compete against.
IRC is battle worn. It's tried and tested. It has extensive support everywhere. It's simple to knock up a client/bot/etc in any language you want (Or using telnet).
It's still used by millions day in day out. Millions use it from websites without knowing that it's IRC under the hood.
It's unsurprising that people are defending the defacto chat protocol. Just as they'd defend email.
I don't really understand the proliferation of group chat platforms. It's been around the since the dawn of the internet, and it already works great (IRC). Do we really need to keep smothering it in new web interfaces?
I recently installed an IRC server on my pi to satisfy my 15-years-old me wishes to operate an IRC server.
None of my geeky friends tried it out, I ended up writing some bots to have a chat with :(.
Seriously, configuring and securing correctly an IRC server take more time that I would like to admit. And it's a bit ugly on the screen and people don't want to learn '/' commands and authentication when skype/msn allow them to do funny things in a much easier way.
I always thought this was just a reference implementation for SignalR. In fact David Fowler is the author of both. I never considered Jabbr a long-term "product", instead just a really involved side project.
Nothing to say a side project could not turn into something much more.
Personally, I see the two complimenting each other.
ie:
- Want to see SignalR in use beyond a small example? Then jump right into JabbR.
- Want to see some not so simple code which utilises SignalR? Then head to their GitHub repository.
- I'm sure SignalR has had enhancements/bug fixes found through the use/development of jabbr.
From what I can see, it looks like a great project that has a lot of potential to grow.
Jabbr has a bunch of content providers built in, so if you pasted a link from say imgur, you (and others in the chat channel) will see a preview of the image. Which is pretty cool, and not something you'd experience in IRC.
To those who are confused by the name, this is not a Jabber / XMPP service. JabbR started as an example chat app for using SignalR[1], an open-source, realtime signaling library for .NET written by David Fowler & Damian Edwards. Think of SignalR as Socket.IO but for the .NET world (and Mono compatible).
This has grown into a more mature self-hostable chat. I just threw a version up on AppHarbor 10 seconds ago and I have to admit I'm surprised by the amount of features this thing comes with.
Side note - If you're curious about how scalable this is, SignalR is built on .NET's IAsyncHttpHandlers & TPL (async made easy). I suggest you take a look at the source code.
1. The name is just fail. Jabber is well known and established. Reminds me of the Python name confusion some company started very recently. Seriously, what do people think when they name their products like that?
2. There are many Jabber OSS implementations for self-hosted chat systems, even for corporations. Why another new system?
+1 for using backbone models/collections for message/messages. I have been working a lot with XMPP and Strophe.js lately. Will definitely give it a try.
Chat is not done right until you include search functionality. There is an incredible wealth of information that is exchanged through mediums like this that just gets lost if you don't have a good search function. So at the moment this is collaborative chat done wrong :) I hope you accept this as constructive criticism because other then that the product looks pretty well designed.
I got the small IT consultancy I work at using hipchat, we love it! The main reason I wanted us to use hipchat versus the conventional IM'ing is for this exact reason!
One thing hipchat needs to work on though is that when you use the search functionality on the windows air app it really just opens a browser windows with the results. This is a little clunky and irritating i think!
Going a step further it'd be nice to easily be able to select snippets of conversation and tag them for later reference or even perform other actions like emailing them.
I hope hipchat continues to develop more functionality that bridges the gap from synchronous communication to asynchronous for utility such as this.
It doesn't seem to have any conventions for dealing with multiple side conversations that inevitably happen when several people are in the same chat room. While it is a hard problem to solve well, I think that is something "chat done right" needs to include.
53 comments
[ 2.5 ms ] story [ 113 ms ] threadAlso on what do you base "no one uses it"?
Probably a positive
> and no one uses it
What in the fucking what?
> it's clumbersome to use in a browser too.
Not really, there are plenty of web-based IRC gateways. Hell, JabbR could pretty easily be an IRC gateway/interface.
> JabbR > IRC
assertion error: baseless
There are plenty of valid criticisms of IRC, but you're completely clueless about them. And it.
IRC is a well-supported, still widely used, open standard for real-time communication. It can work just as fine on the browser with any of the hundreds of browser-based IRC clients. Heck, you could probably hook this Jabbr front-end to an IRC server without much pain.
Jabbr looks nice, but it's just a cute IRC reimplementation.
Edit: Oh, nevermind, I just saw you wrote 'jabbr', not 'Jabber'. See, the confusion already started. Bad product name. :)
http://irccloud.com (Although, lot's of downtime recently / growing pains.)
That being said if this could connect to IRC in a way transparent to the user it would actually be really useful
With that in mind, perhaps the name is a bit confusing?
It's still used by millions day in day out. Millions use it from websites without knowing that it's IRC under the hood.
It's unsurprising that people are defending the defacto chat protocol. Just as they'd defend email.
None of my geeky friends tried it out, I ended up writing some bots to have a chat with :(.
Seriously, configuring and securing correctly an IRC server take more time that I would like to admit. And it's a bit ugly on the screen and people don't want to learn '/' commands and authentication when skype/msn allow them to do funny things in a much easier way.
I should have installed a jabber server.
I do not think it is. Try and be a little original.
Personally, I see the two complimenting each other. ie: - Want to see SignalR in use beyond a small example? Then jump right into JabbR. - Want to see some not so simple code which utilises SignalR? Then head to their GitHub repository. - I'm sure SignalR has had enhancements/bug fixes found through the use/development of jabbr.
From what I can see, it looks like a great project that has a lot of potential to grow.
Jabbr has a bunch of content providers built in, so if you pasted a link from say imgur, you (and others in the chat channel) will see a preview of the image. Which is pretty cool, and not something you'd experience in IRC.
Plus the Jabber trademark is owned by a company, so you'll probably have to change it anyway.
This has grown into a more mature self-hostable chat. I just threw a version up on AppHarbor 10 seconds ago and I have to admit I'm surprised by the amount of features this thing comes with.
Side note - If you're curious about how scalable this is, SignalR is built on .NET's IAsyncHttpHandlers & TPL (async made easy). I suggest you take a look at the source code.
[1] - https://github.com/SignalR/SignalR
2. There are many Jabber OSS implementations for self-hosted chat systems, even for corporations. Why another new system?
3. Website looks awful in Opera.
That said, I'll now commence with a shameless plug: I'm working on a Javascript XMPP chat client built on backbone.js and strophe.js:
http://conversejs.org
Here's a recent screencast: http://opkode.com/media/blog/2013/04/02/converse.js-xmpp-ins...
Patches and comments welcome!
One thing hipchat needs to work on though is that when you use the search functionality on the windows air app it really just opens a browser windows with the results. This is a little clunky and irritating i think!
Going a step further it'd be nice to easily be able to select snippets of conversation and tag them for later reference or even perform other actions like emailing them.
I hope hipchat continues to develop more functionality that bridges the gap from synchronous communication to asynchronous for utility such as this.