Mibbit blog

Just a follow up to the widget moving post. Tomorrow the DNS for embed.mibbit.com will be updated to point to the new widget server. Please make sure you have setup your IRC server to allow connections from the new IP address. If there are any issues please email help@mibbit.com

For those twitterers of you, Mibbit can now connect to twitter and have a twitter tab that periodically updates with any new tweets. You can also just type in the input box and press enter to send a tweet

You can setup your account to auto-connect to twitter, just like yahoo and irc.

Enjoy

If you’re interested in mibbit deveopments (Among other things), you can follow http://twitter.com/mibbit

You may notice that http://www.mibbit.com now shows a brand new updated splash page

If you want to go straight to the chat client, simply update your bookmarks to http://www.mibbit.com/chat/

If you’ve already linked to mibbit using server or url params, they will automatically still work. For example, http://www.mibbit.com/?server=irc.mibbit.com&channel=%23mibbit will still work fine – it’ll redirect to the new URL.

The widget has been improved, so that it now shows any connection errors – this should make it far easier to debug when there is an irc server issue.

Stay tuned for some more updates tomorrow

The widget is moving to a new server, and so some changes need to be made.

1. If you run an IRC network and have already setup a session limit or webirc for mibbit, please add the same for the new widget (widget.mibbit.com 207.192.75.252). Please email webirc with confirmation so that I can keep track of everything, and if needed add the webirc config this end.

2. If you run a website which is using the widget, and know that the irc network has a limit setup for the new server (A list will be put on the wiki soon) do the following:

2a. Create a new widget account at http://widget.mibbit.com/manager/ *OR* login if you already had a widget account setup. A copy has been done of the accounts, so your IDs should work as they did before.

2b. Set your preferences.

2c. Use the url provided in the [Preview] tab, and update your html code.

Note that irc.mibbit.com is setup already, so if your channel is hosted on irc.mibbit.com you can start moving over.

Also note that this is a different server to www.mibbit.com. If you log into www.mibbit.com and change prefs, the prefs under your login in widget.mibbit.com will *not* be updated. Use http://widget.mibbit.com/manager for managing your widget settings from now on.

Thanks in advance for the help in this reorganization. Any questions, come and see us in #help on irc.mibbit.com.

* Tabs on the left work in widgets now, correctly. If you have the space for them

* The new banlist output works on the widget *IF* you are in that channel, or if you have a serverTab. (/mode #channel +b).

* Sound now works on the widget!

* There’s a new [mute] button that appears on the top right of any chat tab/server tab in both the main client, and the widget (If you have any sounds enabled). This means you can easily mute things.

Hopefuly this will give your website visitors an easy way to know when something has happened in the chat widget.

A technical post for a change

As you might have guessed, Mibbit relies heavily on XMLHttpRequest. This is a handy javascript mechanism to request data from the originating webserver.

Every time you say something on mibbit, one of these XHR requests fires off to the Mibbit server to tell it what you said. The typing notifies, when you join a new channel, all communications is done via XHR.

Now the XHR uses straight HTTP as its protocol, which is ok, we can try and make the browser use keep-alive so that it’s all done down the same connection. But what about the headers?

Well, when you’re doing a lot of XHR, the headers can become a problem. We can finely tune the headers we send out in the server response, here’s what Mibbit sends back:

Connection: keep-alive

Content-Type: text/plain

Content-Length: 67

That’s it. We don’t need anything else. Note that the text/plain is needed for some browsers which assume xml and then start throwing hissy fits when it doesn’t parse as an xml document.

But what about the headers the browser sends?

The size of headers in a basic XHR request:

Firefox3: 495 bytes

IE7: 289 bytes

Safari: 357 bytes

That means if your little ajax request is simply sending 5 bytes, you’re still going to send a few hundred bytes. Wasting time, bandwidth, and processing. For XHR requests, you often simply do not need half of those headers. I already know what the user-agent is, and can send it at the start of the comms if needed. I don’t need an Accept header, because it’s irrelevant. The XHR is going to send back text. etc

We can do a little bit better… Here are the numbers when we add a few lines of js to cut down headers.

Firefox 3: 268 bytes

IE7: 259 bytes

Safari: 322 bytes

The code:

setHeaders = function(xhr) {

    function safeSet(k, v) {
        try {
            xhr.setRequestHeader(k, v);
        } catch(e) {}
    }

    safeSet("User-Agent", null);
    safeSet("Accept", null);
    safeSet("Accept-Language", null);
    safeSet("Content-Type", "M");
    safeSet("Connection", "keep-alive");
    safeSet("Keep-Alive", null);
}

All the code does is try as hard as it can to remove headers, or set them to small values. So instead of firefox 3 sending its massive user-agent string to your server *every* *single* *time*, it doesn’t send it at all

There may be other headers that you can remove, if there are extra headers sent. I’m sure the code above can also be improved to take account of different browsers.

Also note that the mileage really does vary from browser to browser. The code above actually increases the headers in opera, as it appends the values. eg User-Agent = null, Opera……

The lack of some headers may affect web proxies possibly – that should be tested. It would be possible to detect such a case at runtime and leave the header in though.

The w3 spec regarding this can be found here http://www.w3.org/TR/XMLHttpRequest/

Mibbit handles an average of about 600 XHR requests a second. That means if everyone is using firefox3, the saving would be 136kbytes/second – That’s 339GB per month!

All in all, this will reduce bandwidth usage for Mibbit and make things just that bit better

You can now customize the user input menu. Enable/disable each menu, and set the colors.

This is handy for if example you want to have a widget on your site, but don’t want to give users the option to change colors.

You can find the new prefs in [prefs]->[input bar]

Some more updates in the works

There’s a new release of the main client, which should solve any comms issues. There were a few odd cases in certain browsers where the sending manager would get an error, and not try and send any more packets. They’d queue up and never get sent.

Also with the new comms there is a little bit of optimization which should speed things up, reduce bandwidth etc.

On irc.mibbit.com we’ve had a few spambots recently, sending links and PMing people, so we’ve beefed up the scan on connection (bopm). If you do get wrongly flagged please email abuse@mibbit.com with the details and we’ll see what we can do. There should also be some notes on the wiki as to how this all works soon.

As far as other work, there’s some *awesome* new features in the works, a much needed update to the mobile client (iphone/ipod), and some widget improvements.

We’re aware of an issue where any “sending” from mibbit stops working. You can still receive chat, but anything you say will not get sent.

I know how frustrating this can be… It’s only happened to me once or twice, but that’s too many times. It’s being worked on, and a fix should be out soon

There are a couple of changes with how JOINs are sent on connection, so I thought I’d post here…

Previously, JOINs were sent on receipt of a 265 stat from the server, OR after 10 seconds. However, the issue with this is that sometimes the services doesn’t have enough time to identify you, which could cause a JOIN to fail on a channel that only allows identified people.

I then changed it to send the JOINs after 2 seconds. This is fine for most servers, but some stall on connect for a while (bopm etc), and ignore the JOINs.

So, the new system released today sends JOINs 2 seconds after the first 005 is received, or failing that, after 15 seconds.

Hopefuly this will give services enough time to do its job, and also mean that all ircd’s that pause on connect will recognize the JOINs