Meebo invented everything for us in 2007(?!)

If there would exists a "Jabber Innovation Award 2007" I would definitely give it to Silicon Valley-based Meebo. Their platform, built on top of libgaim and jabber, offers the following things currently:

• Online Presence / chat widget embeddable at webpages


• Web interface and desktop client support for jabber (your account is user@meebo.org)


• Ad-hoc groupchat functions accessible from any network (through web interface) - most possibly based on MUC


• Embeddable groupchat (MUC) for webpages


• Media-recognition (youtube links are added to a media pool in a groupchat)


• Web-based filesending abilities, even for groupchat


• Platform-independent web-based plugin capabilities, including:


• Voice and videochat support with any users on any network

Pretty awesome list, isn't it?

I recommend to try it for yourself, as I said above, registering a meebo user means effectively having a jabber address - using other systems happen through gaim.

While we're trying to push out new XEPs, they realized two things:

• Web is the platform you should build on, because it's independent from nearly everything, yet quite popular


• If you have a disadvantage (being a browser-based client it isn't fashionable for geeks) you better start to innovate.


• Even if you're based on jabber, you should make sure protocol does not matter: it's the client which does the user experience

If we could only ask them, how they achieved this, and how we could make this a common knowledge of humanity and ourselves!

(The author still dreams of having an open meebo platform-like solution for desktop clients too through standardizing and WebKit/Gecko/CHtmlView)

XMPP services as OpenSocial providers?

I'm just looking at the freshly-out OpenSocial API by Google, and a few others. While there's a lot of rationale behind how and why the Facebook platform works as we know it today, I understand such a system would be hard to use generally for a lot of social network providers, therefore the OpenSocial API is much simpler.

Looking at the API, it feels to me it perfectly fits some usual PEP-PIP-POP, (generally P.?P:) scenarios, and since some of the major XMPP server vendors contain a built-in webserver already, it shouldn't be hard to do as a module for them.

What would be the benefit of providing such API? Building systems on top of XMPP allows us to deploy services in the social web scene, which did not get jabber yet as much as it could be.

Push e-mail: are you kidding?

I've heard recently that Enterprise IM is the the most popular "web 2.0" tool amongst corporations.

When I asked my cousine, working for a large and well-known company in New York, that why don't she uses their own IM system, just gmail. She told me that they don't use an own IM system.
I asked:

- Do you use blackberry?
- Yes
- For Push-email?
- Yes
- That's IM.

Come' on: it's Instant and Messaging. It does not have presence subscription, but it does have a roster (it's only called Address Book). Surely it has advantages (people who "has an older version of internet installed on their computer" can communicate with you), and there are disadvantages as well (they don't see how busy you are, therefore they can't decide if it's important enough, something which could be solved with presence).

But before trying to hurry your marketing departments to advertise XMPP as a free alternative of Blackberry, you should first migrate from the old system. What am I thinking about?

1. Write a component which is compatible with push-email, so they don't loose functionality
   
2. Write a component which is compatible with postfix, qmail, whatever smtp servers are popular nowadays, to work together with XMPP servers - this way creating an XMPP-based free push e-mail alternative
3. Write a client, preferably for mobile phones where this transport could be handled conveiently.

Come on, it's your turn EIM jabber vendors: there's a market ruled by a ridicolous propiertary system, which could be easily overriden by just a tiny piece of software - an SMTP server module which catches e-mails and acts as a transport.

Jabber aliases / j2j gateway

I have more jabber accounts than an average guy has an e-mail address. As Jabber usage will start to grow, and different communities and organizations will adopt Jabber as their choice of communication technology (rather than today's e-mail, or e-mail-like systems found in forums and social network sites), we'll have to find a way to connect jabber accounts of a person into one (or a few) bundles.

Of course, there exist approaches like Psi's multiple account system, as well as using Gaim, or other MPIM for jabber purposes, but none of them is a real, protocol-level solution.

But we can do this by Jabber-To-Jabber transports, like j2j does.

It's a XEP-0114 compatible jabber component, so it's suitable for most jabber servers.

I was constantly asked for this feature, mostly to connect gmail accounts into a new system, so here it is. Thx for Steve for recommending.

Why xmpp4moz needs to be a standard: What's wrong with XEPs?

This post is a long-awaited post for me, but I felt the motivation again after viewing and browsing Douglas Crockford's videos about JavaScript.

First, let me tell you that the IM war is mostly a war on user experience. The more fun the user can get with a given IM-solution (by which I mean both protocol, client, and service provider), the more possibly he's likely to use it. There's nothing with the network effect here: if we really wanted, we could already solve that with transports!

What is jabber? It's

• An open network with many service providers


• A core protocol (standardized in RFC 3920 and RFC 3921)


• A set of optional extension protocols, called XEPs

The fate of CORBA

Of course it's nothing a user deals about, it's the thing evangelionists care about, which is nearly good enough. Corba was such a protocol in the nineties, with a core protocol, and a lot of extensions. It was born for interoperability between vendors.

But: Corba isn't used today mostly. Corba died in the fact, that most of its parts are optional - this way there's practically no two "ORB"s, which could communicate with each other - sometimes even from the same vendor on two different platforms! This way the open ecosystem of CORBA components simply never were to be born: it was always vendor dependent, and gave its place to other vendor-dependent (Java RMI, .NET Remoting), or more formal (XML-RPC, SOAP WebServices) protocols in order to achieve a greater interoperability market, not to mention JSON and other grassroot standards.

It cannot be argued that a network supporting all the XEPs currently in draft, final or experimental would be superior to most of today's IM network. But there's no such network, and without changes it isn't likely to be born, even if XMPP is the only standing standard between formal IM protocols. As one on jdev expressed:

We already won, it's just the thing nobody noticed this except us.

What's the problem with this XEP thing anyway?

The jabber network - by which I mean the open network of providers supporting the XMPP protocol - is a heterogenous environment: not only there are different server implementations and policies, but there are different clients as well. There were 10 clients with a larger marketshare than 3 percent on jabber.ru last month! And that's only one of the service providers, with a popular and feature-rich server implementation. What could those users on that network do with each other? It was determined by:

• The core protocol support itself


• The support of extensions by the server implementation


• The support of extensions by the client implementations

What was the largest denominator? What was the bottleneck? I think you already guessed:

An XMPP network supports those XEPs which are supported by all (or vast majority) of the participating implementations - both servers and clients.

Which exaggerated means that

The open jabber network practically does not support (almost) any XEPs, because there's always a client or server between a large share of pairings which does not support the given XEP.

In need of the algorhythm

XEPs are basically data formats to be exchanged between two parties, but sometimes they even define a protocol of interchange. But what could a client do with plain data? Of course nothing. It needs an algorhytm to process the data and give an answer. Since the XEPs theirselves aren't formal definition in a computer science perspective (using SHOULD and MAY is formal for a human, but not for a computer). The former JSF process put the implementation in the hands of client authors, making it the responsibility of them to implement them. Of course, every client author picked up their own choice of implementing XEPs, and there's hardly an intersection between them.

So what we would need is either:

• An official repository of processing alghorythms with formal description, which means in some kind of computer language, to which an interpreter/compiler could be written for clients


• Make the processing instructions travelling with the data package, possible with weak linking (eg. a processing URL)

An official repository could be needed if the processing could do malicious or privacy-problematic things on behalf of user, either centrally, or by signing it with usual keys (eg. a client could accept a corporate SSL certificate to use their implementations in an EIM environment, and official XSF-signed extensions).

Representation

Of course, if we have the data, and have the alghorythm, one could argue, that a layer is still missing: the view layer. And one could argue that this should vary from client-to-client, but if we do inspect today's popular IM solutions, we should find out that all of the corporate rivals (MSN, AIM, YIM, ICQ, etc) use an HTML rendering system in that layer in official [windows] clients; while it could be argued that some XMPP clients does not, but it does not mean it's a right way: by using the broad market of HTML rendering engines (Gecko,Webkit, Windows' CHtmlEditCtrl...), a lot of diplay problems could (and should?!) be solved.

There's even a space for interactive applications, like board games, crayon-based whiteboards (which I really liked in Yahoo!'s IMVironments), all which could be done by using a proper HTML-based rendering engine and some common features which all clients could share.

While HTML is in itself probably a bad idea, XHTML isn't much difference, while it's still XML. Therefore, XSLTs and CSSs could still be used over it, giving a client's own look and feel. XSLT is also formal: it could give XSF a tool by which recommendations could be written into XEPs.

Hey! It would be even useable on webclients and an iPhone :)

A processing language for view layer?

It's also arguable that XSLT in its own would be enough to write collaborative applications, games, etc, but hey, we already have a good view-layer language: it's called JavaScript, and its core features are used in many interactive application frameworks, most notably Flash and XUL. And this is again a part where HTML rendering engines come in: they have a natural support of JavaScript.

But there's also support (or, to be correct, a variant) in Flash, in Java (have you heard of Rhino?), in KDE applications, and in C: basically everything. Webclients are in fact written either in JavaScript, or its variant, ActionScript (OK, there's Jeti as an exception, I know), so they could also have some support of collaborative JavaScript applications.

The way xmpp4moz works

xmpp4moz by hyperstruct thinks XMPP of a communication layer, on which collaborative applications could be built. It uses the XUL variant of JavaScript [unfortunately, but we'll deal it later], which means it makes the browser-application "presence-enabled" so applications written in javascript could talk with each other. Of course there are security restrictions: namely an application could only catch those messages which are for the conversation the application currently runs in (can be a MUC or a private conversation). While it's strange for the first minute, since there's no authority, and any webpage could use some collaborative features by using this framework, it's a viable decision.

After all, it's a good thought: collaborative applications resides on their own webpage, and they can be used by calling them from a presence-enabling framework; this would fit very well to the web ecosystem. This could be a browser, or a desktop client.

The only problem is that xmpp4moz uses firefox-only javascript methods, which are good if you want to expand firefox's possibilities, but is a very wrong approach when you want to design a new collaborative application standard, but it's not a thing which couldn't be solved: after all, both XIFF, JSJaC, libstrophe-JS and xmpp4moz should have their common denominators. But I left this to solve for You.

(All the above text is merely a personal opinion, sometimes perhaps made more pessimistic than in reality to catch attention and start arguments; it's not an official statement nor I think the XMPP world is simply wrong at all.)

After-meetup links

Hi all,

So, meetup was held, here are some links:

• My presentation in English and Hungarian
  
• Custom Smiley Handling in Jabber
  
• The two introduced systems: Jive OpenFire and ejabberd
  
• A blog comment from twitter senior developer Blaine Cook about twitter and jabber (look for "In principle, I Agree")
  
• JsJabber (educational javascript client)
  

And here are the five key thoughts I wanted to share, with a very little explanation

• Innovation: The fact that you can build your own userbase, and run your own independent service with just using standards, and that you can extend them is the key component in success of web 2.0 and GSM-networks (in this case: http, html / xhtml, ecmascript, and oma/3gpp standards)
  
• Service-based distinction: Although you could build an own mobile network which outsiders can't use, of course, it will be possible, but I hope that in most cases you still think it ridicolous. You distinct your own users from outsiders by advanced [innovative?] services and prices, not by not allowing them to talk to gmail users just because "it's a rival". [This was a reaction for freemail's closedness]
  
• Mash-up: It's better to show your users your own extension protocols (like Gmail does for Gmail notifications and others), so others can remix it; and it's better to use some remixable system like SamePlace, to open a whole new ecosystem of plugins (Note to self: we must find a way to standardise html/http based collaborative application building like which is in sameplace)
  
• Word-of-mouth Of course you can't tell everybody to use Jabber (but you possibly have just enough media to place it before your users), and can't officially do an MSN-gateway for a large hosting; but you can let this information spread.
  
• At home: Install a jabberserver (like ejabberd or openfire),and try it for yourself
  

(Presentation and key messages slightly differs!)

As you can see, it's a mashup-point-of-view: it's been a popular theme in Hungary this year, and I think we have seen just enough walled gardens here at home to try if we do it better this way.

Oh, presentation is CC licensed (as all Budapest New Technology Meetup presentations)

JsJabber: Educational client in javascript

Here is my educational client, built with PWC and jsjac. It does not have presence changing feature, it just shows how a jabber client could be done. Feel free to use it.

(Was done in a few hours, probably would be good for a quick workshop:)

JsJabber client homepage

(You can test it in Firefox with a Jo-hely (good places) account, registration is free (Hey, my team built it ;)

For those for whom it does not work, a screenshot:

Unified IM network in Hungary - what would YOU say?

I'll have the oppurtinity to talk about 'Unified IM network in Hungary?' in a five-minute session on The Budapest New Technology June Meetup, which will be visited by nearly everyone who counts in the social media industry.

The excerpt of the presentation is:

Everyone knows GTalk; some may know, that is based on a standard protocol, jabber (XMPP). T-Online uses this for messenger in Freemail. The presentation would be a five minute summary of what is jabber, how one could start a service fast and simple, and what could we gain if we could make a unified network of this, and what problems could arise.

What would You, dear reader of mine say, if you'd be in my position?

Facts:

• There are 4 major players in Hungarian market, one of them is T-Online.
  
• Privacy and security is not an issue (yet) in Hungary (people don't think of it too much, won't be profitable)
  
• Nearly everyone has an MSN account (unfortunately), so we have to say what would happen if Jabber would be put under everyone's nose (in webmail and in... and in what?) Why would they switch if at all? Why would it be better?
  
• Hot topics are: eventing (mainly twitter), and social networking*, in which monopoly could be broked also
  
• Internet penetration is about 34-38%, mobile penetration is above 100%, although mobile internet/wap is rarely used (or it's used by the 60% rest who does not use internet)
  

So, what would you say?


* (we have some social network sites, most popular is property of T-Online, called iWiW (Who-is-Who?). Although it's not very customisable, when someone logs in, basically could reach everyone's data: name, location, about myself, reach addresses (e-mail only shown for 'friends' by default), 10 MB worth of pictures, one embedded video from youtube; mostly used features are pictures, searching; average connections is about 300-400 per user)

General PubSub (PEP) receiver?

Recently, Artur Hefczyc from Tigase project implemented a StanzaReceiver module, which is, simplified, a general pubsub-like interface, but uses a general <message/> stanza with body instead of pubsub stanzas.

This gave an idea of having a general event receiver component of clients: if a pubsub / pep node can't be handled by one of those special protocols (like: User Avatar, User Tune, etc.), then just pop up in a window somehow.



(Mockup created with OmniGraffle, using CC photo from flickr user Bhalash, just to give the credits.)

Why?

Client compatibility is always a bottleneck. If we do PEP a general protocol over User Tune, User Mood etc, we don't have one new protocol to implement: we have a new one for every capability. Isn't it easier, to, let's say, have a "<human-readeable/>" field for every possible solution, and if a client can't handle such event, well, it simply falls back to a default method?

Basically, we still have 3 types of messages: a direct one, a broadcast one, and a get-set pair of them. We know that we just want to 'broadcast' something, in hope that this will be understood by most of our peers - but what happens if not? I think end users would benefit from such.

I don't want to force anybody to anything, just trying to get the flexibility of pubsub and the obvious reasons why StanzaReceiver was created get together :)

Future of internet

In the last few days I didn't have constant internet connection - The network was demolished about two weeks ago, just before we moved, and there's no connection yet at the place where we live now. This way I could understand the importancies of my online life, and with a little background, I realized some things. First of all, I realized that IM was my most needed feature, the second one was e-mail, then community portals I'm on came, and just then news sites and blogs came. And I also realized it wasn't an accident.

I'd like to congratulate Evgs and the Bombus team from this place: they made my life a lot easier in the past few weeks, and their client is wonderful, does more than a lot of desktop clients, yet it was suitable for my phone, even for my old k700i.

So, let's see the basic lessons I've taught:

I'm only interested in internet when there's people behind there.

That's what web 2.0 is about in fact. For years, I've been working on CMS-solutions, making portals to enable target audiences to reach the information they want - but that's not the internet I was really looking for.. I was on e-mail lists with other developers far away talking about software projects, on IRC channels with beloved girls and friends, then blogs and social-network mania came. Now the actual hype is around Twitter which is again not about great solutions.

I understood this as my possibilities to get online shrink, I wasn't interested in news portals and blogs, whatsoever. I wanted to read my mail, and get in touch with my friends on IM - most of them are already online on jabber; mostly they use gmail or gaim-like clients.

But it's just one concrete thing, let's see what it is about in general.

When I read my n-th science fiction book (this was currently Solaris, and n wasn't a too small number), I told my friend on art faculty, who's an expert on cyberpunk and SF, that "yup, it was good. Yet is about people too.". He answered: "Good literature is always about people." (Creditz goes to Kelt). Let's do a generalization from this:

Good media is always about people.

I guess you do have your own celebrity magazines in your country - at us, it's called Story, but probably you have Hello, or anything other - and have your own series, wether it be brazilian ones like Rosalinda or action ones like 24, CSI, any other. Besides the obvious action - part and the exciting story it's about people - probably that's why Desperate Housewives, or ER or Grace Clinic is so popular. But they aren't real people: celebrity magazines have the need to write about our false friends: we see them every day, and probably some of us are interested in their personal lives. But what about the people around us? You can not see this at a magazine... Oh you can: that magazines are called myspace, facebook, twitter, you see this every day.

Mobile internet is about realtime communication.

Heard it that 'develop for mobile, use css because soon mobile clients will came and flexible layout would be important, everyone would read e-books so paper books are at risks and anyway, mobile is the future, ahoy, mobile internet!' I've been hearing this for years now. But I remember when my mother gave me my first mobile phone - none of my friends had mobile that time - that she gave me this to "always be available". But mobile doesn't do a good job at this: I don't know if I call somebody where will the call find her: at home, at bus, at school, being with her lover... you just don't know that simply. Probably you fear that it will find her at wrong time, that's why you send an SMS: not too interactive, although it has delivery receipt feature, yet you don't know if the recipient was really available and when will an answer come if any.

I used my mobile phone to tell my friends where I am now, and mostly to ask help - they were besides real computers, with enjoyable internet connection (mine was gprs 4+2, which means basically dial-up speed), not to mention that firefox and opera maxi (tm :) were compatible with "normal, usual hungarian web pages" where most of the information I wanted to reach resided. It was fun to have the instant availability of my friends in my pocket, that I could chat along a long journey with them if there were nothing else interesting. And I always knew who I can chat with, and answers came instantly.

(Note: I was using T-Mobile GPRS Net subscription, which contains 50MB of data transfer per month bundled in the subscription fee - since I use it for jabber only, I'm not talky enough to overrun this just by chatting :)

Of course, not "realtime" and "always-on presence" are the only key concepts of future mobile technology, but I'm sure they're one of them. Sorry for bothering you with such general posts - I'm preparing some research papers now on Jabber, so next time I hope I could provide you with more concrete, protocol and a bit implementation-related things :)

Freemail and jabber

[This post was originally in Hungarian on my personal blog, and was sent to some people inside and near Hungarian ISP T-Online, which owns freemail. Freemail is the oldest e-mail service in Hungary, with roughly 3 million users, that wasn't updated for many years. In March, T-Online announced the public beta of the new freemail, which has a built in IM-client in javascript built on jabber, and a SIP client (for which T-Online has already a desktop VoIP client, called Klip, since 2005 or so) in java. But the jabber service is only available through the web interface (yup, http-binding), and no s2s is allowed.]


Dear T-Online developers,

First, I'd like to express my happiness about that freemail has chosen the standard, open source - rooted Jabber / XMPP protocol instead of proprietary solutions. This - because of the amount of users - is a big step in the history of jabber service too: to the usually cited 50 million users this 3 million growth is significant, let alone considering the internet penetration in our country [it's about 30-40% on 10 million people]. I hope that soon every Hungarian internet user could have a Jabber account, what could cause an innovational movement unprecedented in Hungary. I believe, that there's much unexploited potential behind this technology, and that it can develop further in an open competition, in a market-oriented environment.

MSN-compatible custom smiley handling in Jabber

It's an ongoing university project run by me with the much appreciated help of Peter Saint André and others.

You can read about it here.

Twitter posting bot implementation

This is a fast-and-dirty hack to enable posting to twitter. It uses Smack, the java library OpenFire (formerly WildFire) and Spark are built upon, and I used the same IDE (IntelliJ IDEA) which is used by Jive Software to implement their (wonderfully clean-coded) software.

Basic "disadvantages":

• No bothering with config files (educational purposes) => account/password, admin hardcoded


• Also, since educational purposes - public domain! (you'd modify an existing source to learn jabber anyway)


• Uses apache's java HTTP client library - a simple auth to twitter and a POST


• User binds twitter account by sending a register <twitterusername> <twitterpassword> message to the bot.
  
• Doesn't save its state (bot stops => twitter account data lost)- could implement with Serializable markerinterface


• Doesn't use session-handling: logs into twitter every time; normally, twitter api would need to remember session cookies for each user/pass and trying to simply post the status variable, and if fails (with errorcode 403 presumably), relogin and store session cookies again


• No multithreading - if twitter is slow, the bot stops responding while doing HTTP query. Normally, at least two threads (one for the twitter api and one for the XMPP connection) should be used.


• No selective presence/multiple resources/etc - load balancing could be done with bots with same accounts but different resources and probably selective presence/invisibility

You can download java sourcecode here.

The needed libraries - which aren't in public domain(!) - are boundled too.

Jabber client example in KDE/QT

This is a small client I developed for educational purposes on top of KDE and gloox (for simplicity) in C++.

Basic ideas:

• Jabber data processing needs a loop and/or an event handler (depending on architecture). Most graphical systems will also need one, this can cause problems. In this example, we used QT's idle processing feature, which called a single cycle of Gloox's message processing. A kgloox wrapper class was written for this.


• In case writing a client application (not a bot or likesome), we need to connect conversations to windows. Most users feel comfortable that they have one window for each contact (or at least, each resource). Because of incoming messages, we'll need a mapping of contact -> window, and also a window->contact mapping. Although the second one could be stored in the window class itself in some environments, the first one will definitely need some window manager object. Some would argue that it's just a matter of observer pattern, but I'd say that it's easier to implement this way, because of contact we haven't opened a window for yet.


• In most of the time, we need to subscribe to specific kind of messages, like messages of specific type (message/presence), of specific origin (given user), or specific namespace (feature query). It's a good idea to have some general handling pattern of such - like, observer pattern, signal-slot mechanisms, or packet catchers/interceptors. It's also a good idea to make it either hierarchical or precisely catcheable (like a PresenceProcessor class catches all <Presence/> stanzas coming from a JabberConnection class, then individual viewports could catch for a specific user, ie. when a window is open with a given contact, it's a good feature that you could see when the contact goes away.)


• It's good to have separate layers of application: not all the components would be responsible, for example, processing of Jabber XML streams, nor all the layers have a hardwired reference of UI.

You can download the KDE source here.

Requirements for build:

• KDevelop, KDE libraries,etc


• gloox (0.9-pre5)

It was coded with kdevelop because it's easier to write it in an IDE, it's c++, not javascript... ;)

Screenshots

Jabber introduction slides

I've created these slides for university, it's a short introduction to the jabber protocol.

Indented for: techinical people, who heard of jabber, probably used it, but never went into "how it works" questions.
Not indented for: Those who now what iq, message and presence stanzas stand for :)

Hungarian contains thesis examples too (MSN-like custom emoticon handling, music streaming as presence information, etc).

Hungarian version

English version (without thesis examples)

Introduction

A beginning is the time for taking the most delicate care that the balances are correct

Princess Irulan (Frank Herbert: Dune)

Hi. My name is Adam Nemeth, known as Aadaam. I'm a software developer from Hungary, EU. For years I've been using ICQ, as it was the first instant messaging service, and for me, it was a standard, too. However, as years passed by, more and more instant messaging solutions came, the (at least in my viewpoint that time) ICQ-clone MSN Messenger, and the peer-to-peer VoIP software Skype.

I first used Jabber protocol sometimes around 2004 or so: I heard of it before, and some of my friends used it ocassionally, but it was a struggle with icq-transports and clients of that time. But I realized that ICQ is just a service, and as more and more people starts using instant messaging every day, we need to consider it as a part of a communication solution - most of the universities, student clubs were already providing e-mail and webhosting services, as well as some forum and so on. Realtime is getting closer as our life gets faster every day.

When Google introduced its XMPP-service called Google Talk, I was way in jabber: I knew how to use the protocol with a pure telnet, knew how to write a client and even had some ideas how to use it on web with XEP (or, at that time JEP) 124. Now I see it as a communication standard.

But much work has to be done: for example, it's not clear how we could use alias and forwarding features of e-mail. It's not clear how we could connect to accounts to each other. Practically only ejabberd provides virtual hosting, and erlang is an unusual language for an average programmer working with imperative code like Java or C++ or whatever.

There's also a problem with the protocol design itself: given that you have a heterogenous network with all kind of clients, the interoperability between those is the intersection of the supported XEPs of all clients; as more and more clients come in, it gets worse. We need to bundle the logic with the XEP itself, and there are some very good experiments out there for such.

We also need to make jabber easier to spread: embeddable clients in webpages, open hosting providers, etc... its not as easy as it seems but it can be done. Also we need a lot of features from other networks - in Hungary, mostly MSN is used today, because of custom smiley handling, for example. Teens love it, and can't imagine a client without that feature- it'd be 'boring'.

This blog will focus on mainly three topics: first, and not least, possible use cases on jabber services. Then protocol implementation examples, with simple, educational scripts in GPL or even public domain. And also there'll be some discussions about possible new protocol extensions, like the above mentioned custom smiley protocol I'm designing.