Hi,

here a short and long awaited update on my Google Summer of Code work. I've been finishing the update of libpurple's Entity Capabilities implementation to the latest version and added a bit functionality so that 3rd-party plugins for Pidgin can query for some contact's capabilities or adding capabilities to Pidgin's feature list which they implement. It's been tested and seems to work. Thanks to Arne König for testing all this and giving useful feedback.

During the last weeks I've added TXT record lookup to libpurple's asynchronous DNS lookup system and make libpurple automatically query for Alternate Connection Methods for XMPP. The end user won't notice much of the underlying mechanics but if she/he is behind some firewall with HTTP proxy and the XMPP service administrator has setup the right records and services libpurple will automatically use BOSH to login and everything will be nice.

Onto new business. I've started implementing a HTTP 1.1 stack which is nearly finished. I've already started implementing BOSH which is based on this new HTTP stack. The great thing about it is that I use Safa Sofuoğlu's Google Summer of Code project, which is about improving OpenFire's BOSH support, for testing. So if I implement according the spec and something doesn't work I can directly report the errors, discuss them and get them fixed quite fast. The best of all will be a XMPP server supporting latest version, version 1.6, of BOSH in form of a connection manager part in OpenFire and a client supporting the latest BOSH.

The next week I'll try to get BOSH at least working and do some debugging and cleaning here and there. If I don't get it finished till GSoC deadline I'll finish it later on.

Cheers and happy coding,
Tobias

Here I present some charts on XEPs, XMPP Enhancement Proposals, and their development. You can see, most XEPs are either in Experimental or Draft status. The one and only final XEPs are currently:

• XEP-0077: In-Band Registration
• XEP-0030: Service Discovery
• XEP-0009: Jabber-RPC
• XEP-0004: Data Forms

There have been two XEP source files unprocessable in XMPP's repository because of invalid XML and since the reposity only exists since end 2006 no longer history was accessable.

These charts have been generated by OpenOffice.org and some custom python script which worked on XSF's svn repository.

jabberd2 win32 project is finally updated and synced with changes made in the generic Unix code. New changes should bring improved compatibility & stability and new 2.2 features for Windows users. Binary installer and optional build instructions available as usual at jabberd-win32 page. Click more for changes.

Changes:

• FIX: Setup files were not anymore compatible with latest WiX 3 beta
• FIX: Router failing opening users and filters configuration in Windows
• FIX: Mysql missing crypt is replaced with DES_crypt from OpenSSL in Windows
• NEW: Compressed stream support via zlib
• NEW: Keep server.pem on upgrades
• NEW: Using SubWCRev from TortoiseSVN for version files generation (instead of xsltproc)
• NEW: All configuration files are now generated on build by Perl from generic distribution ones
• NEW: Using udns library for Windows builds too (resolver component was removed)
• UPDATE: Synced config.h with the one from generic builds

All changes are visible as SVN revisions 644-688 in the repository.

Please note new build prerequisites such as udns, zlib, Perl and TortoiseSVN for manual builds.

Since XMPP is (becomming) the biggest player from all the instant messaging protocols out there, there are a lot Google Summer of Code™ projects in the XMPP field this year. BOSH, the highly discussed dream team for connecting to XMPP from mobile or other limited network environments, is covered by a lot projects this year.
My GSoC project is, not only, about adding BOSH support to libpurple, the C instant messaging library which powers desktop clients like Pidgin and Adium and web clients like Meebo. libpurple doesn't only cover nearly any proprietary instant messaging protocol but also some open protocols like IRC, SILC and of course XMPP. For XMPP, as the (future) major instant messaging protocol, it's most important that XEPs get implemented, coded and used in real life. There is a huge number of XEPs which aren't implemented and may never be, who knows.
I will implement BOSH from the beginning since there is no codebase in libpurple in the BOSH field and just contacted Safa Sofuoğlu, a GSoC student for the XSF mentoring organization, who updates Openfire's BOSH implementation. We plan to test our implementations of the two XEPs, XEP-0124 and XEP-0206, against each other since he'll write a server side implementation and I'm writing a client side implementation.

Our aim is to have not just working and good performing implementation but moreover implementations according to the two XMPP Enhancement Proposals. I'm looking forward to the inter-project collaboration.

Cheers and good luck to all Google Summer of Code™ students,

Tobias

Have you ever wished that you could chat with your family and friends in your native language? Sometimes there's just no substitute for expressing a thought in your own language. Google Talk now has transliteration bots that will convert text from English to Hindi, Kannada, Malayalam, Tamil or Telugu. Think of a bot as an invited guest to your chat session that will transliterate what you type in English to the right local script. For those who are not familiar with transliteration, it is a service provided by Google India that allows you to type in Indian languages using phonetically equivalent English script (it is also available on our labs page, orkut scraps and blogger). If you're chatting in Hindi, when you type 'haal kaisa hai janab ka?' the en2hi.translit@bot.talk.google.com bot will reply in Hindi as 'हाल कैसा है जनाब का?'

There are currently 5 transliteration bots - Hindi (en2hi.translit), Kannada (en2kn.translit), Malayalam (en2ml.translit), Tamil (en2ta.translit) and Telugu (en2te.translit), and remember that their names end with "@bot.talk.google.com". To use one of these bots follow these three steps:

1) First add the bot that you want to your friend's list. (For example, add en2hi.translit@bot.talk.google.com for Hindi). You just need to do this once.
2) Start a chat session with your friend
3) Convert the chat session to a group chat and invite the bot to it.

Read this to know more about the bots, and let us know what you think.

तो शुरू हो जाइए...





Kuntal Loya
Software Engineer

A few days ago I have silently uploaded tigase-livecd-4.0.0.iso file into our download section. Even there was no announcement the download counter shows now 145. I wonder if there was such a big number if people knew what they are downloading....

Anyway. This ISO file is the first release of the Tigase LiveCD version. It is a complete environment runnable from the CD with pre-configured Tigase server, Drupal CMS (Blog and Forums) and Dovecot - IMAP4 server integrated together. The Drupal CMS runs with the Minichat on the example website. The live CD is based on the Gentoo Linux.

In this particular case integration means all services (Tigase, Drupal, Email) use user accounts from a single database. The user account management is done via Drupal website.

You can also post short news on the website directly from your XMPP client, you will also receive notifications about comments and posts on the website to your XMPP client.

The live CD contains also 2 nice XMPP clients: Psi and Coccinella in the most recent versions. Hm, Psi has just increased version number so it is not the most recent.

Everything installed and pre-configured, starting up automatically when the system boots from the CD.

read more

If you have not seen this yet, you really need to check it out. Or even give it a try. ;)

http://www.youtube.com/video_response_view_all?v=3YAIVQ_oh88

Over on the JUser discussion list, someone asked why there’s less spam on the Jabber network than there is on the email network. I answered as follows:

I’ll have to write a paper about this sometime, but here are some points
to consider:

1. In XMPP, the sender’s address is not asserted by the sender’s client but instead is stamped by the sender’s server. So a client can’t fake the “from” address. (Naturally if you run the server you could fake addresses at your domain, so as the admin of jabber.org I could send messages from any address at jabber.org — but I can’t fake messages from other domains, see #2.)

2. In XMPP, servers check each other’s identities, either through a DNS-based “dialback” protocol (RFC 3920 / XEP-0220) or real server certificates. So if I run a server at jabber.org I can’t send messages putatively “from” microsoft.com or whitehouse.gov or whatever. (Also we don’t have multi-hop routing, so modifications to the addresses can’t happen between the sending server and receiving server.)

3. So far, server dialback has been sufficient to prevent most address spoofing on the network, but we have a certificate authority in place (visit https://www.xmpp.net/ for details) and we could fairly easily upgrade the network to certificate-based authentication between servers if needed.

4. XMPP is pure XML, and attackers can’t easily attach malware like scripts and viruses to Jabber messages. This helps us avoid the unholy alliance between virus writers and spammers that has occurred on the email network.

5. A great deal of email spam (or spam+malware) is directed against a single platform: Outlook running on Windows. In the XMPP world we have a much more diverse software ecosystem.

6. In IM systems, people are accustomed to sharing presence / adding someone to their buddy list. There’s less of a culture of “I must be able to accept messages from anyone in the world” as in email. You can say this is good or bad, but that’s how it is — so if someone bothers you, you can delete them from your friend list or block them at the server side (see RFC 3921 / XEP-0016) or the client side.

7. All XMPP server codebases have rate limiting in place to prevent a single client from sending a large number of messages (especially a large number of large messages) in a short period of time.

8. Although we have not seen very much one-to-one spam on the Jabber network (our biggest problem so far is abusive behavior in groupchat rooms), we are actively planning for the arrival of spam and have designed some spam-fighting measures such as challenge-response (CAPTCHA) forms to join groupchat rooms or add someone to your contact list — see XEP-0158.

9. IM systems have traditionally been quite fragmented (and in many ways still are — as witness ICQ, AIM, MSN, Yahoo!, Skype, etc.) so there isn’t the expectation that you’ll necessarily be able to send a message to any random person on the Internet. This probably makes IM less appealing to spammers than email is. (Remember, spam is a matter of economics, and there may simply not be enough money to be made via IM.)

XMPP is not perfect. Spam is possible on our network, but it’s not very easy. By design, spam is harder on the XMPP network than it is on the SMTP network, and if spam does start to occur more widely we will design and deploy even better spam-fighting tools (or, for instance, tighten up or turn off in-band registration, which is user-friendly but also makes it possible to create lots of accounts at multiple servers).

However, XMPP does not need to be perfect. You don’t need to be the fastest antelope in the herd to avoid being eaten by the lion, you just need to be faster than the slow antelope who get caught.

Peter

UPDATE: A lively discussion has ensued on the list — you can participate even without joining the list by visiting JabberForum.org. I’ve also received a number of private messages about the topic, so I may post about it again soon. :)

Jabber technologies have always been optimized for sending many small pieces of structured data, which we call XML stanzas. As a result we’ve struggled with ways to send binary data — even small bits of binary. Out of that need emerged XEP-0231, which I recently renamed “bits of binary” (a.k.a. “BoB”) because I like catchy spec titles (hey, it’s one of the things that keep me going). Folks like Ralph Meijer have had vague worries about the approach we’d taken in that spec, but we needed it for anti-spam CAPTCHA forms so we kind of brushed those aside because we need to fight spam, right?

Then over the last few weeks Pavel Šimerda raised some further concerns and, more productively, suggested solutions. So Pavel and I have been collaborating on revisions in a longish email thread, in a groupchat the other day, and in follow-up email thread. Pavel has been a pleasure to work with and it was fun to make such significant progress in such a short period of time.

Best of all, I think “BoB” is one of those building block technologies that we’ll be able to use for features like emoticons, thumbnails for file transfer, in-line images in messages and whiteboarding sessions, and yes those CAPTCHA forms for joining chatrooms or initiating presence subscriptions.

So here’s to BoB! :-)

I try to put a lot of examples in the protocol specs I write (as I like to say, “we put the example in example.com”). So when Jeff Williams of Gadgetworks recently noted on the jingle@xmpp.org discussion list that a number of the examples in the Jingle specs are not valid in accordance with the XML schemas (or even well-formed), I was chagrined but also intrigued. Off-list, Jeff and I have worked a bit on the Jingle examples and schemas, but he’s found it painful to manually extract all the examples from the specs for testing purposes. So late this afternoon I wrote a small XSLT to automatically extract all the examples from a XEP (wrapped by a <stream></stream> element) and write them to a file. I’ve run the transformation on all the XMPP extensions we’ve published so far, and the results are available at <http://www.xmpp.org/extensions/examples/>. I’m sure there are many errors to be found (e.g., I know some examples don’t parse because they include things like “[...]” in place of elided markup), but we’ll work to clean those up over time. Feel free to report any errors to me directly, or on the appropriate discussion list. Have fun!

The results of the XMPP Summit a few weeks ago continue to leak out. I’ve been so busy with action items that I haven’t had time to blog about it all, but I did want to note that over the last few days we’ve worked out the remaining details about how to use OAuth to access protected resources over XMPP. Read all about it in the latest version of XEP-0235. Special thanks to Ralph Meijer and Blaine Cook for setting me straight about a number of issues on the social@xmpp.org discussion list.

I submitted two XMPP themed proposals for SXSW 2009.  The interactive panel picker is now open, so please go vote for my entries if you have any interest in XMPP at SXSW.  As far as I can tell, I’m the only one speaking on the topic.

The first submission is a panel called “The XMPP Powered Web“.

XMPP is being used to build the next generation of Web applications. The open messaging standard has crossed from the desktop to the Web and is powering applications for microblogging, gaming, social networks, communication, and data portability. Learn how others are using XMPP and how you can use it, too.

I am planning to invite some well known developers using XMPP for interesting Web projects to join me.  Google, Flickr, Seesmic, Chesspark, and others are already building on XMPP technology into the Web, and it is time for the rest of the world to get into the game as well.  Vote here.

The second proposal is a solo talk about XMPP basics called “X Is For XMPP: An Open Messaging Primer“.

XMPP is an open, extensible messaging standard designed for instant messaging and presence. The protocol is based on XML and is simple and easy to understand. XMPP can be used to power next generation Web apps. Learn how XMPP works and how you can use it in your own applications.

I’ll cover the basics of the protocol and dive into various ways XMPP can be used.  I’ll cover the big XEPs like Pubsub, BOSH, and MUC, as well as topics like using components and writing bots.  Vote here.

If any of you are planning to be at SXSW 2009, let me know.  I’d love to meet more people building cool things with XMPP.

Credit: freebird4, License: by-nc

There has been a lot of news in the Tcl/Tk community the last month or so, and I thought it's time to compile them here since Coccinella is written in Tcl. Tcl's windowing toolkit, Tk, has been "known" to be ugly and outdated. With the 8.5 release last December the tile package, now named ttk (Themed Tk), is included in the core which brings true native widgets on Windows (yes, Vista too) and Mac. Since Mac is my native platform, I can tell you that Tk beats both Qt and gtk, but perhaps I haven't seen the latest of them.

The question is then, where does this put Linux/Unix? There are a number of themes included in ttk which looks OK on these platforms, but there is nothing exactly like Qt or gtk. Instead, there have been a tileqt package written by Georgios Petasis which has delivered true Qt widgets. With ttk in the core, there have been some initial problems getting this to work due to missing stub tables etc., but it should work with the latest Tcl/Tk 8.5.3 release.

Just a few days ago the very same person announced tilegtk which does the same thing for the gtk toolkit. This is very, very, good news. Imagine that you can switch theme, and toolkits, on the fly without any program restart. This already works with the other themes and will likely work with tilegtk as well. My question to you is: which other toolkit has this flexibility?

I have already mentioned my recent advances with tkpath in this blog thread, and I will mention it again. This is the super canvas which is lacking in Tk, and which will bring not only tight SVG support, but also make Tk come on par with canvas like widgets from other toolkits. Still more to do.

Recently my attention turned to WebKit which has its history of its own. Dual licensed as LGPL/BSD it fits the Tcl community well. I have looked at some of the sources, and judging from the wxWidgets backend, it doesn't look terribly difficult to make it a Tk widget, but there could be show stoppers, like event loop integration etc.

When all this comes together it will make Tk a very competitive toolkit.

Too much time have passed since my last post... Huh? It was the beginning of my last report month ago. Sadly, not too much progress due to personal problems. Time for real speed-up. Anyway, Psi will have new history system no later this Autumn. :)
Two recent days was great. 2/3 of code was refactored or rewritten. Now it's much better and clear. You can see it and add comments at gihub. And new GUI looks better too:

Do you think it looks good? or bad? Please download and try. Git's black magic:
git clone git://github.com/AlekSi/psi.git
cd psi
git branch --track fake_backend origin/fake_backend
git checkout fake_backend
git submodule init
git submodule update
cd proto
qmake (or qmake-qt4 for Debian-based distros)
make
./proto
Comments are needed. :)

read more

We do like the long release cycles, it seems.  :)  Kev the project lead has written it up on his blog.  You can find download links on the Psi Download page.

Say hello to Psi 0.12. Thanks to everyone involved in this or previous releases.

New in 0.12
- Multi-user chat windows now join one on one chat windows and can be opened in tabbed form, either sharing a window, or seperately.
- The roster search has been updated, and now triggers a filter when typing into the roster window.
- An XML ringbuffer is now used, allowing access to already received XML in the XML console.
- When resolving a name for new contacts, the full name is now used if the nick name is missing from the vcard.
- Auto-connect on wake is now an independent option.
- MUCs can now be bookmarked, and auto-joined.
- The old config.xml file has been dropped in favour of the new options.xml format - all options in Psi can now be configured from the Advanced options pane (no more hand-editing of config files is required).
- Vcard avatars are now transmitted for the benefit of legacy clients and servers not supporting PEP.
- A new diagnostics group is available in the help menu, to allow debugging problems with the QCA security layer.
- Launching several instances of the same profile on Windows and Unices with DBUS now behaves more sensibly.
- On X11, the taskbar should now flash on new messages for compliant window managers.

Downloads from http://psi-im.org/download/

It’s been a long time since last report, but don’t worry - I’m still here, trying to make new roster working until the deadline.

Currently, I’ve got new roster as separate window launched at psi startup. It can display some roster items (contact, resources, accounts, groups), filter them and keep itself up-to-date with XMPP stuff, but it doesn’t respond to any actions.

In next few days I’ll be adding other types of roster items (transports should be done today, then self contact and “not on the list” tomorrow; did I forgot about something?) and search. With that done, I’ll finally be able to plug in context menu and other ac

tions and have semi-usable roster (hopefully) by the end of this week.

Sure there’s still a lot of stuff to be done (most of it is written down on wiki), but these are the last ‘big’ tasks, rest will be just simple improvements that should not raise many problems.

In short, I think that the project is going quite well and if I start working just a little bit more, I should be able to meet a deadline.

Disclaimer: sorry for the boring post, next one should be more interesting since there’ll be some stuff working (at last!). Feel free to poke me on jabber if I do not post anything here within a week, I tend to forget about blogging

UPDATE: There’s not much too see here, but here’s a screenshot showing joined accounts view with avatars and status messages as well as (in this case Remko’s) resources on roster.

Last week I was refactoring TLS code in gajim to fit the new architecture. Debugging of XMPP over TLS on 5223 and 5222 (with negotiation) wasn't difficult because wrappers for python stdlib ssl and pyopenssl are well designed (by dkirov I think). Now I'm on securing the HTTP connections which can be non-persistent and thus more prone to error occurrence. Good handling of various TCP and SSL

A lot of code has been written since last report, while refactoring and creating new plugins. Details follow.

The goal of this part was to close elements related to GUI extending and, generally, plugin management. Some clean-ups have been made also to prepare code for events handling part.

First of all, a few changes have been made to PluginManager class - even if plugin is deactivated it is an instance object, not class object. This gave opportunity to add init method, where devs can put some base operations that does not depend on plugin current activation state (speeds up plugin activation).

The biggest change is connected with plugins configuration. It is now fully-featured, based on shelve and UserDict modules and transparent to plugin developer. Config files are not plain-text, as this is Python pickling, but you can easily save dicts, list, tuples. In future, this will be probably rewritten to some custom class and integrated with Gajim’s main config facility.

I’ve written new plugin: Banner Tweaks (based on patch by pb), that allows people to easily achieve compact banner in chat windows (difference can be seen on screenshots).

Old plugin Message Length Notifier has configuration window now, so it’s fully usable (see screenshots). I’ve also added JIDs filtering feature to it (for which JabberIDs notification should be used). To show roster extending possibility I’ve written small plugin, Roster Buttons that adds quick access buttons to it - one of them shows/hides offline contacts (idea taken from Psi).

Aparat from that, extension points cleanup mechanism has been added, so dead references are kept no more. In addition, needed modifications have been done to Gajim core and plugins.

What’s keeping me busy

I feel obliged to inform community about things that have influence on my time dedication to GSoC project. First of all, I’m very close to finishing my master’s thesis - delays were maybe mostly because I started (again) reviewing state-of-art of information retrieval and what impact can it have on my project. Great reading of a lot articles published by Springer and IEEE.

Second of all, and it this is more important, I gained the title of Certified Project Management Associate, after passing IPMA lvl D exam. Looking at list of certicate holders in Poland. I’ve realized that I’m one of the youngest persons on that list (AFAIR second or third in row).

Open-Source feelings

At the end, I just wanted to write that Yvesf wrote LaTeX Plugin using API in my branch (haven’t played with it much so far checked it out and it works nicely). Great feeling to know that someone else starts to use your code Probably this is one of open-source rewards…

Tigase.org website, e-mail, SVN, XMPP and all other services have been successfully migrated to a new server at the external service provider.

Let me know if you find any problems with the website or any other services.

I hope this solves for good problems with availability and accessibility to the Tigase.org services.

read more