Until we do know more about it, we can look through the Wave protocol draft spec, and notice that its built on top of XMPP.

At the same event, the new XMPP-powered mini applications where also announced. Each one is a XML file with all the HTML, CSS, and JS files packed together. Time to see how long it will take a XMPP desktop client with access to a WebKit view to implement this extension. It reminds me all the discussions about embedded applications we had in the API mailing list last year.

I'll keep it running in case you need a guinea pig for tests.

Very good news.

The AnyEvent::DNS module allows you to resolve DNS queries fast and in parallel.

To test this, I wrote a simple command line tool to check XMPP SRV records of a list of domains. Both server-to-server and client-to-server records will be checked and results printed out. All queries will be made in parallel.

The code is at my Ironman repository. Click the "Raw" link to download (sorry, no direct link, GitHub lacks permalinks to the latest raw version of a file).

But Kevin is not out of the XMPP client world. He and Remko announced a new cross-platform client called Swift.

Not much is known for now about Swift but I expect a bit more news over the weekend.

While we wait, I'll leave here my wish list for my next client. I don't know if Swift is going in this direction or not, this is just me thinking out loud:

• C/C++ minimal core: the core is responsible for XMPP connections and stanza parsing;
• HTML-based UI: all windows are HTML-based. If they choose to use Qt, they would be WebKit views. The DOM of those views would be extended with XMPP-oriented objects;
• JavaScript-based application: the IM logic is written with JavaScript, manipulating the XMPP DOM objects and the HTML-based UI;
• Plugins: all features should be written as plugins. I should be able to drop a directory with HTML, CSS, images and JavaScript files and hook that into the XMPP dispatcher. It should be possible to hook using XPath expressions, so that I can build new protocols with ease.

We can dream, right?

Good intro, solid presentation. Go, read.

I didn't have Keynote.app on the laptop where I wrote it so I decided to try S5 to write my slides.

The HTML version is great, and with a bit of syntax highlighter even the XML examples look good.

But the PDF version is very basic. I searched around for a better CSS to print S5 slides, but could not find anything. Maybe CSS is just too limited for decent printing control.

I don't know if I'm going to use it again. The lack of a decent PDF output is a big minus. On the plus side, I really like having the full power of HTML/CSS/JS inside my presentations.

As for the code examples, I wrote two:

• a basic HTTP-to-XMPP gateway: post stuff and send it via XMPP to someone;
• synchronize several processes to execute in a sequence (for example, restart a web farm, one web server at a time) using a chat room. Includes an auction (very simple, assumes everybody plays fair) to determine the final sequence.

All examples are written in Perl using the Net::XMPP2 framework. I made a few fixes to some of the Net::XMPP2 modules, you can find them inside the repository to make running the bots easier. I'm going to send Robin Redeker (Net::XMPP2 author) those fixes, so they should appear in a future version.

The blog post mentions the usual suspects: XMPP for signaling, RTP for transport and a H264/SVC codec. The implementation uses a browser plugin. Time will tell if this plugin will be bundled with Chrome (most likely) or bundled with Gears (would make sense for Google).

The Mac installer includes a meta-package with two packages: Keystone.pkg and the GoogleVoiceandVideo.pkg.

The Keystone.pkg includes the GoogleSoftwareUpdate.bundle that is installed at /Library/Google. Inside it has a GoogleSoftwareUpdateDaemon but so far I don't have it running on my system.

The GoogleVoiceandVideo.pkg is the real deal. It installs several things:

• two QuickTime components, Google Camera Adapter 0 and Google Camera Adapter 1;
• an Internet plug-in, googletalkbrowserplugin.plugin;
• an GoogleTalkPlugin.app support application.

After installation, it opened my GMail account and detected my iSight camera. I wasn't able to find someone to use it with so far, so I'll report back on the quality of the image. I expect a decent quality given the chosen codec.

I'm focusing on Codebits right now, so not much time to check out the XMPP part of this, but it seems to me that then reused the same signaling already used by the Google Talk client, nothing new there.

The big question for me is this: will other sites be able to use this plugin for their own video-chat features? I need to read the license more carefully.

As for Skype, it still has one advantage: I can use it without opening a browser on my Mac. But if I where them, I would start thinking about XMPP support and interoperability with Jingle, but thats just me.

Skype window of opportunity to be the leading XMPP client is shortening every day.

So get of your collective chair-interface-parts and send your ideas.

Thanks!

I also have a slot to talk about XMPP and this is where you can help.

I don't want to do another abstract talk about XMPP, but instead I want to write code that you would like to see.

So if there is some XMPP-based functionality that you want to see how you can get it done, ping me or email me with the high-level details.

I'll take all the projects I can cover in an hour and present my skeleton or even complete solution at the conference and discuss why it was done that way.

All the code will be available before the presentation so you can also follow along.

I spent an enormous amount of time there and I still have fond memories of that time, of the people, the stories, everything.

But access to Moosaico (and other MUD's or Talkers) is usually done with Telnet or using a client like TinyFugue or Atlantis. Keeping one of those open to be connected somehow never entered my normal workflow, so I drifted away.

Its amazing that something that I was hooked on 14 years ago is still alive in me.

The friday something happened that will pull me back in.

Another friend, Marcos Marado, commented that he was looking for a XMPP interface to his talker, Selva. I had an headache and didn't feel like working on what I was supposed to, so I took the challenge.

Later that afternoon, Rasputine was born.

Rasputine (or Ras, as Corto Maltese called him) is a generic Moo/MUD/Talker-to-XMPP gateway. You add a buddy to your roster and then you can use it to connect to that world.

For example, to log in to Moosaico, add moosaico@rasputine.simplicidade.org and then type //connect. Presto, the login window of Moosaico should be readily available. The Selva talker is available at selva@rasputine.simplicidade.org.

The code is still very young and feature-less. The copy that I run on my staging server already has per-user status messages and avatars, and next I plan to implement auto-connect (probably even XEP-0100 support).

For now, I'm just enjoying getting back to Moosaico.

Update: by the way, if you want to connect your own talker/MUD/Moo, ping me via XMPP or email and I can set you up. At least to try it out.

(via IMtrends)

I gave a presentation entitled WTF is XMPP? mostly centered around non-instant messaging applications of XMPP. I think it went well, the room was pretty full and I talked a lot with people after the event which plan to use XMPP in the short term.

The organizers did a wonderful job, and I want to thanks Alcides to push me to write the presentation.

Update: cool, the presentation was featured on SlideShare homepage.

Kevin, Peter and Remko are hard at work for O'Reilly to brings us the XMPP missing book.

Entitled "XMPP: The Definitive Guide", it should hit the shelfs in 2009.

Shameless offer: if you need technical reviewers, you know my JID :).

It seems to be MUC-based, not PubSub. I hope to see a future version with PubSub in the future.

I used the Net::XMPP2 Perl module, in particular the Net::XMPP2::Component class. It uses the AnyEvent async framework, which in turn support the EV library , giving you all the love of kernel polling.

Until the Net::XMPP2 author releases a new version, you should use my own copy if you plan on doing external component work (check the component-reply-with-from branch). Net::XMPP2 is widely used for bots, but not that many components, and some methods need some love to work properly in a component environment.

The HTTP part was done using the excellent AnyEvent::HTTP class. I'm using my own version, which includes a bug fix to the http_post function (on its way to release 1.03 of AnyEvent::HTTP) and adds support for HTTP::Request to http_request. I hope to see this included in the main AnyEvent::HTTP distribution but I still need to update the documentation.

The rest is just glue code.

These are some suggestions that bot authors can use to increase your XMPP presence easily. I'm going to stick to easy stuff only, most of it widely deployed.

The first thing that you need to understand is that you can have different per-contact presence information. You can switch the status message and the avatar for each of your contacts. Its called directed presence (basically include the contact JID in the to attribute, but you can always check the spec for directed presence).

You can use this to provide a personalized status message for each person on your roster. If your service has a notion of context, you can use the status bar to show the current context. For example, imagine that you have a ticketing system bot. You type "working on TICKETID", and your bot can change the status message to "Working on: TICKETID - TICKET_TITLE (URL of ticket)".

Optionally you could update the status each five minute with the elapsed time since you started working on it.

You can also switch the avatar. Maybe switch to a red background, meaning that you are busy doing something, or putting it in another way, the bot is telling you that he thinks you are working on something.

Other stuff you should do is to provide an alternative representation of the information you send textually. Twitter (when it used to work...) was a great example of this: every tweet you received by IM, included an Atom entry with the most important information of the tweet. This allows client to improve their interaction with such services, by using a more appealing interface.

But Atom entries are not yet standardized by the XMPP Foundation (there is some effort on Atom over pubsub that could be used as an example though). On the other hand, Data Forms are a standard, and more, they provide interaction possibilities.

You could send a "New ticket" notification, including a data form with the structured information, and a select-box with the possible next steps. The user would see the form, and submit back their decision.

Still in the subject of messages, you should know that there are several types of messages. You have chat, headline and normal (strangely enough the default). There are two more but not important in this context. You should use the correct one depending on the type of message you are sending.

If your system is just sending notification, please use the headline type. It makes it clear to clients that they are not chatting with you, just notifying of something that happened. For example, a smart client can react to those messages differently based on your status: in away, xa (extended away) or dnd, a client can keep a log of new headlines and show it like a email client when you return, without interrupting your workflow, probably using a badge with "You have X pending headlines".

The final recommendation: respect the user status. If the user is dnd, are you sure you should send him anything? Why not change the status message to "You have 5 messages pending. Send 'pending' or go to URL to see them"? Maybe even change the avatar color. You should not disturb someone in dnd. I would also say that away and xa are off limits but that's just me.

On the other hand, you should send "Hey there, welcome back! You have 5 pending messages. Send 'pending' to see them or hop on to 'URL'." when the presence changes to chat or available (not a real <show> value, just lack of <show> value. See the valid values of <show> and their meanings in the spec).

Have fun implementing your bots.

Thats a lot of new victim^H^H^H^H^H^Husers to the XMPP network.

This, and the fact that my Google Alerts on XMPP is now showing about 10 hits per day (from less than 10 per week just 18 months ago), and I would say that XMPP is turning out to be one hot technology at the moment.

Update: given that the news came up via the official Facebook developers site, some people have IM'ed me asking why the question mark in the subject. Well, I'm waiting to see if they will open federation or not. Using XMPP is more than allowing Facebook users to use their favorite XMPP client to chat with the other Facebook users. Without open federation, this is just another private IM network and I think we have enough of those.

So the question mark is there until a answer is found for "Will Facebook enable open-federation over XMPP?"

One problem was that open-source servers did not implement PIP/PEP. Recently this has changed, with both Openfire and ejabberd having decent implementations. Other servers, though, are still MIA.

Also of note, GTalk does not supported it yet. This is a bit of a problem due to his visibility in the XMPP community.

So if you do implement it in your client (and I think you should, really), it seems that you have to keep using the current protocols for avatar (for better or worse XEP-0054 plus XEP-0153) and server-side storage (XEP-0049).

There is something that servers could do to improve this situation though. There is a small change that would give client authors even more good reasons to implement PIP/PEP today.

If private storage and vCards are implemented on top of PIP and PEP, we could have the best of both worlds.

From the point-of-view of current clients, nothing will change: they will still use XEP-0049 to set and get their private storage nodes, and they will still use XEP-0054 to publish and retrieve their vCard. But at the same time, each private storage item would also be available in a PIP node, and the user vCard would be available in a PEP node.

This would allow PIP/PEP-capable clients to announce support for vcard-temp+nofity namespace in their disco response, and get instant notifications of vCard changes. Also, announce storage:bookmarks+notify and clients that only support version 1.0 of XEP-0048 will immediately support version 1.1.

This could be a easy way to increase supply of nodes, to see if we can reach critical mass sooner, in the move to a pubsub-world.

Of course this sent shock waves through the XMPP community, not because they where totally wrong, but because they didn't have the vision to solve it.

We of course understand that they have their hands full (of vapor, some bad mouths would say...) getting the platform in shape for the late 2008 release, and the XMPP.. err, sorry, GTalk protocol is not a top priority.

Well, today Android users around the world can rejoice because once again, the XMPP Standards Foundation has risen to the challenge and unveils to the world the solution to the "verboseness" problem, by introducing the breakthrough Binary XMPP protocol.

This has been in development for quite some time, taking long hours of (sometimes) heated discussion. The goal is to have something that nobody could ever accuse of being verbose (the symbol count is extremely low, and the meaning is clear from the start), but at the same time remain compressible for those extreme cases where bandwidth is at a premium (we tested, and we have code to prove it: a Binary XMPP stream can be compressed to 2% of its original size). We know of clients that live in five-sides-shaped-buildings that, with their hard 9600 baud limits, will be the first to use this.

Its been a great ride, and it feels me with immense joy to be able to put my small signature as a co-author of this spec. Of course, my part is extremely small when you have the documentation genius of Peter Saint-Andre, and Fabio Forno strict guidelines and requirements, as co-authors. Its been a pleasure to work with both on this. And I should also thanks the important Kevin Smith contributions.

And now time to rest. SRV records are up at simplicidade.org domain, and Fabio's CM is running also.

PS: and yes, now you know why the prolonged silence around here.
PPS: for those who have moved on, the code is also available on GitHub.

So now is the time to stop using it. I'll unsubscribe the MSN account from the Gateway, and I'll no longer be available on the MSN network. You can add my XMPP address as a buddy: melo@simplicidade.org.

Right now, you have a lot of open and decent XMPP servers out there: SAPO Messenger, Google Talk, Jabber.org and a lot of others. So there's really no excuse not to have an account on one of them.

So hop on to the clients list and join the fun side.