How Google pulled the plug on the public Jabber Network

I know I'm late but I still can't see this part of the deal showing up...

So, it's no news that Google first disallowed new s2s connections, then started their own protocol, which has no s2s connections at all.

With that, the largest node of the public Jabber network went down, incorporating the largest share of its users. They're pointing to spam:

Chee Chew said that "we haven't seen significant uptake" in federation with Google Talk via server-to-server connections. The majority of the uptake Google did see was from organizations or individuals looking to bombard Google Talk users with chat spam

Ars Technica

And also did the original dream of Jabber.

By assigning server identity as a hostname, servers are also able to route data directly to each other and their connected clients, thereby creating a new, inherently open IM network out of all the individual installed servers and clients.

Jabber internet Draft

There is no open IM network anymore: we have some walled gardens supporting the XMPP c2s protocol for easy access.

For years, I've been dreaming - and trying to get funds - for a mail system competing GMail, but being compatible with it both in e-mail and IM - that's not possible anymore.

I was urging Hungarian e-mail providers - some of them providing their own XMPP implementation - to allow external IM connections between each other and gmail - that's not possible anymore.

The open network of communication won't be brought by XMPP, that's for sure.

Jabber failed to provide good enough spam protection, failed to provide a scalable protocol, failed to provide easy transfer of accounts between providers (if I change e-mail address, I don't have to re-add all my friends, it's enough to set a simple forward or inbox pulling - that's not true for Jabber IDs!)

Besides, no matter what was the dream, it turned out, the complexity is mostly on the client side, and that IM networks are inherently complex. We had a lot of clients able to transfer basically text-only messages. Not even files.

Also, given the fragmentation of the community - it's not a product, it's a protocol community somehow - Jabber failed to gain developer interest it seems - instead of Jingle, the way for A/V communications seems to be WebRTC now.

For message broadcasting and queing, there are a lot of protocols available. XMPP is one of them. For me, XMPP was an open protocol and network for human-to-human communication, and it seems it has failed its mission. It's only used as a fallback protocol for IM clients.

So, it seems we're struck with walled gardens for a while again.

Jingle FT - the million dollar protocol

I was speaking with Florian, one of the board members of XSF, and showed him my pattern about HTTP-based filetransfer in IM clients, just as done by Beejive or Meebo.

As far as I remember, the filetransfer argument - namely: it doesn't work in XMPP with 5 parallel standards - was settled down by requiring everyone to implement the most complex one: Jingle File Transfer.

It's like saying we don't need filetransfer to be implemented at all.

Jingle is a such complex protocol, that most of the client developers won't even try to implement it. It's just huge. Even Google didn't really succeed with their own implementation (remember the Cricket:: namespace??) and we don't speak about server-side requirements yet.

The XMPP community is constantly ignoring the fact that we're living in - albeit perhaps the end of - the web age. XML was proven to be inefficient, no matter how you compress it, it's just isn't par with JSON or other formats. Pull parsing technique requires special parsers to be written for XMPP, meaning loss of reuse (although they give the stanzas to normal parsers afterwards), Nokia didn't take XMPP in its production phones for efficiency reasons and all the social networks - facebook, hyves, meebo, gmail - implement their own client2httpd solution instead of the inefficient BOSH.

You can joke about it, but the reality is: XMPP is likely to be superseeded sooner or later.

Google took the API step

Just to remind: even if nobody seemed to care after my controversial talk on XMPP Summit this year (not that most of you believed such at all), Google took the API step.

(For a rant on APIs, see my previous post and the ones listed at the beginning of that)

I know SamePlace was much before this, but, with all the credits to Massimiliano, GTalk has a much larger user base.

Now, what we need is a standard API above Meebo, SamePlace, and this stuff, like Ajax did for the XMLHttpRequest implementations

Active resource representations - aka OEmbed

(Note: this isn't a jabber-only posts, although one of the earliest implementations is in Google Talk Gadget, and the jabber community could benefit from this in general)



PHP-OEmbed project page

Remember when the newly introduced Google Talk Gadget displayed Youtube videos instead of showing their links? That's what I call "active resource representation", because it represents the given video more [inter]actively than the pure link - which is hardly showing anything in the case of youtube.

I believe that a resource usually can be equally represented in a small place: there's no need to load a full page to view a youtube video or a flickr photo, but there isn't need for it to look at a person's social network profile, to accept/reject a calendar invitation, etc - and all of these have URLs nowadays. These technologies could be used in e-mail systems, forums, and chat clients.

What OEmbed does, is that it tries to provide metadata about a certain resource found at the given URL. That is: you send the link of a flickr photo, and you get an XML or JSON-formatted structure back. While it can be argued, that these could be / should be / in an ideal world, would be solved by HTTP headers, this is not the case, and this solution isn't as bad.


I tried to do a server-side PHP framework, which talks the OEmbed protocol for clients to consume, however, it makes you be able to create non-oembed compatible wrappers too (the perfect example is youtube, of course). This could be used in a web-client, given that it talks back javascript to you.

Currently, it can handle (proxy) any OEmbed provider (given that you enter their respective address into the providers.xml file), and it has a Youtube provider, which uses some not-so-official part of the "official YouTube Data API". New providers can be added by looking at the provider API - oh, and there's no error handling yet, so you could understand the code :)

Note: I extended OEmbed protocol a bit, namely:

• There could be a description field for every OEmbed-entity (handy for tooltips)


• There could be a duration part (in seconds) for video embeds


• The original resource URL could be in the data response

Oh, and Flickr: please add thumbnails! Thanks :)

Widgets, Xiclets and the REST

It seems Fabio Forno and Pedro Melo are also brainstorming on some kind of "widget-technology" for jabber, and the same applies to me. I've written several articles in the theme, see:

Why xmpp4moz needs to be a standard: What's wrong with XEPs?
XMPP services as OpenSocial providers
Meebo invented everything for us in 2007(?!)

Why do we need such? Let's see:

• HTTP is one of the most succesful protocols


• It has the following extensions currently in use:
  
  
  
  • HTML 4.01 (or XHTML 1.0) for presentation
  
  
  • CSS 2.0 for design
  
  
  • ECMAScript 3 (JavaScript 1.6) for interactivity (with an included DOM API, and with the lack of threads, therefore it should use asynchronous requests)
  
  
  
  

See? Nothing else. No JSRs, no XEPs, no "MAYs", just these three.

Does it solve all problems? Not always, but mostly. Does XMPP solve all problems? Not yet.

Now let's get back to the topic specifically.

The thing is about code mobility, and now we can safely reference to the original REST article (which isn't as bad as restafarians usually are): http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Let's have an application, residing on a certain location (URL), being it chess, or a flash-based videoconferencing/VoIP tool; of course, for interactivity, at least two instances should be run, one at each participating user. We can use either the fact that modern IM-clients use an embedded browser to display conversations (official AIM, Y!M, WLM; Adium), or some kind of integration between the IM-client (eg. pidgin) and a browser (eg. firefox). What could this look like?

The design issues we met are:

1. Features provided by XMPP
   
   
   
   • (RealTime) Communication channel between two application instances from the same source
     
   • (RT) Communication channel between an application instance and the participating users
     
   • RESTRICTED? Presence information of the participating entities (users + bots)
     
   • STRICTLY RESTRICTED: Roster information + all contacts' presence of the user
     
   
   
   
2. Features provided by HTTP
   
   
   
   • Remote script inclusion (like: Google Gadgets)
     
   • Developers MUST be able to write XMPP-supported applications in pure web-style (eg. PHP scripts)
     
   • It SHOULD be easy to adopt already written applications for the new platform, either which uses real-time communication and those who aren't
     
   
   
3. Features derived from browsers:
   
   
   
   • Ability to run javascript applications
     
   • Ability to display XHTML + CSS
     
   • DOM API (perhaps E4X as well? at least, at a later time)
     
   • Sandboxing and cross-domain code execution
     
   • Some kind of interaction between the XMPP client (which SHOULD be able to be a web-based client too!) and the application
     
   
   

Restricted features could be accessed if certain security checks are met (like: the page is from HTTPS, signed by an acceptable authority, like the enterprise running the XMPP infrastructure, or an official XMPP extension); This was done for years with java applet/midlet technology.

Our current example is a Go (simpler than chess) client which should be written in pure PHP + JavaScript (not because we ourselves cannot use more sophisticated, but it's the lowest entry barrier)

Another good example is whiteboarding, it's done such way in Yahoo! Messenger.

We'll see if we could extend it further.

Hope we could meet at DevCon and have a conversation about that (but it shouldn't stop you to comment :)

Open Source Nights presentation

I presented a few hours ago on Open Source Nights, hosted by my long-time friend and ubuntu advocate Szilveszter "Phanatic" Farkas about jabber.

I quickly translated the slides, you can read them in English here or in Hungarian here.

All in all, it was a good evening, hope it will bear us some deployments, or at least, jabber users :)

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