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.)