antecipate

Basic instincts

2006-12-16T10:22:00.000+01:00

What an interesting statement issued here after yet another superficial interpretation of the well known and long identified dual model for IT applications distribution.

At present, there is no one company covering these issues comprehensively. Microsoft must build scalable presence, Google must build trust. At Jabber, Inc. we're watching this looming battle with the inherent interest of an arms dealer.

The author is by the way Jabber Inc's public relations person. The actual issues referred to in the post are

The inherent need for a high trust level that must come associated with any application service provider.
The scalability of the distribution system's architecture to support the service.

I somewhat agree that presence is called to play an increasing role in many upcoming applications, be they used in an ASP or edge model. But this is certainly not the unique constraint that one needs to consider for building a successful ASP infrastructure. Generic reliability, graceful degraded functions, high availability and self healing are just a few of the basic needs for a proper scaling architecture. Real time oriented data services will certainly also play a role. In that respect, Google probably has an edge.
On the other front, I am not certain any of the two contenders can pretend to inspire a sufficient trust level. But, contrary to infrastructure, this is not a technical matter.

To conclude, although I have unfortunately observed several times that many in the PR world often associate “public” with “dummies”, I find rather curious to compare carrots (the illusive trust level of a corporation) and apples (the forbidden fruit of seamless scalability). More interestingly, I am wondering if the author is not falling into that category of people spending 5 months of their year's time in front of a television or a computer. Beyond the natural mental mimetism which results from trying to penetrate DoD contractors defenses and sell them presence, too much exposure to WoW, "GI Jane", [insert here any other B TV series, video game or reality show] is the only rational explanation I could find to why the inherent interests of this company should be those of an "arms dealer" when the context is "live" services…

Technorati Tags: XMPP, Jabber, Presence, Antecipate

Google Mail and Talk outage

2006-12-15T10:22:00.000+01:00

Even Google is not king of 5 nines reliability...

Around 10:15 am (Central Europe time) GMail started spitting out "Server Error We're sorry, but Gmail is temporarily unavailable. We're currently working to fix the problem -- please try logging in to your account in a few minutes." POP access was also timing out from standard email client. At the same time logging onto GTalk would lead to contact lists in error

<iq type="error" id="aacca" to="jlseguineau@gmail.com/psi100C6E2E"></iq>
  <query xmlns="jabber:iq:roster">
    <error type="wait" code="500">
      <internal-server-error xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    </error>
  </query>
</iq>

Around 10:30 the contact list access was re-established, and normal operations resumed on GTalk. But GMail was still unaccessible. Only towards 10:42 did it come back to a pallid life, but even at that time some function of the interface were spitting operational errors. UI functionality came back to normal around 10:45, with SMTP out re-established around 10:47, but at the time SMTP in was still not restored. In addition, the content of my "sent Mail" folder had disappeared... At 10:52 SMTP in was restored and I was able to receive some earlier test messages. Still, not all of them, as they were held back on their originating server following the outage, waiting to be retried later. At 10:57 the content of my my "sent Mail" folder re-appeared. And at around 11:02 the service was restored to its normal working state. In the end, the recovery was well orchestrated, and Google has certainly put some thought behind its procedure. Every external access was degraded gracefully, be it POP/IMAP, web UI or XMPP. Similarly, the service came back to life gradually, without spike, with different functions being restored independently. This incident brings to light some of the architectural options they took, and show how their messaging infrastructure is integrated.

In particular, contact lists are definitively shared between mail and instant messaging, which is why GTalk showed partial service outage when the contact list service was not operational. It also mean that Google could very easily come up with a presence enabled address book where end users could aggregate their contacts.

In the end, although I experienced a mere 40 minutes of inconvenience, the service was restored to its full capacity through what look like an entirely automated process. Lesson to be learned by some would be web 2.0 entrepreneurs…

Translating between otherwise incompatible networks

2006-12-14T17:22:00.000+01:00

This is the most common definition given of a gateway in the telecommunication context:

A gateway is node that translates between two otherwise incompatible networks or network segments. Gateways perform code and protocol conversion to facilitate traffic between different architectures.

On the ground of this definition, the application that IBM has built on its Websphere J2EE server for Sametime is effectively a gateway. For that exact same reason, I believe that a very substantial leap of faith is required to envisage that it could lead to a multi-protocol presence server.
Fom the information available, the gateway is an application build on the JSR-000116 SIP Servlet API. It is in its way following a similar architecture of what IBM tout as the Websphere Presence Server. The SIP Servlet API is an attempt at leveraging developers' knowledge of HTTP web containers and extending it to SIP. On paper this is a sensible idea. In practice it has a few drawbacks.

First, it is entirely based on the SIP protocol, which means that applications built on top of this technology will be SIP applications. As such, the SIP servlets are designed to process SIP requests and return SIP responses.
That somewhat restrict the scope, as each network protocol has very specific characteristics which are rarely though of as "universal". Moreover, not every presence protocol uses a request/response paradigm in the way SIP does. XMPP for example uses simple notification packets to signal modification in presence sates, without requiring these packets to be answered. In that respect, it becomes more difficult to mold XMPP into a servlet paradigm in the way it was possible with SIP. Consequently, the advantages expected from a common programming paradigm become somewhat blurred.
Second, it relies on a J2EE server to run. One can argue that it is a proven robust architecture. I would simply say that J2EE servers were not invented to provide solutions to real-time communications problems, but rather to bring solution to transactional application problems in the enterprise. The table herewith summarizes the differences between the two contexts.

All in all, if the IBM gateway had been implemented using a more appropriate application server such as a JSR 22 JAIN SLEE API implementation, I would have been tempted to take the leap of faith. Unfortunately, this gateway architecture prohibits any use beyond bridging between SIP and other protocols. To be fair, the same inability applies to the equally shortsighted approach taken by Jabber Inc. A solution that only sees the world through the eyes of a particular protocol will always leave us far from what is necessary to build a multi-protocol presence server. For the simple reason presence encompasses more than just protocols…

Technorati Tags: XMPP, SIP, Presence, Antecipate

Ready for personal presence solutions?

2006-12-13T17:52:00.000+01:00

Mike Gotta had a dream: a presence aggregator service on every Windows workstation. If Microsoft could execute on this excellent idea, this would bring them back to the forefront of the individual applications scene.

As in most disruptive changes, the issue will certainly not come from the technology side. What Mike calls a "headless presence client aggregator" is nothing more than a publish/subscribe broker where address handles are used as topics... I think that technically, it can be implemented in no time. If this service is aggregating presence information at a client level, the required processing power and memory footprint can be kept very low. A documented API would allow both applications and "watcher" clients to subscribe or publish information to the common presence aggregator, ending up in a fully layered architecture that could benefit any application running on the workstation. The secret here would be to keep it simple.

The unknown lies in the incontrollable urge Microsoft always exhibit to "control the world" when adding feature to its flagship products. For this aggregator to succeed, it would have to be open…

If this presence aggregator imposes a particular communication protocol, such as the RTC flavor of SIP/SIMPLE, then the adoption would be severely impaired. On the contrary, if the aggregator is open to other communication protocols, and provide by default both an RTC and an XMPP transport, Microsoft would be sending a very strong signal to the industry.
If the rivalries between different Microsoft line of products were ironed out and they agreed to use this service rather than creating their own version of a presence aggregator, they would certainly be sending a strong trust signal to their user base. And as the API would be publicly documented they would not be accused of creating an unfair advantage for themselves.

In the end, there are many "if" for a somewhat obvious and rational solution. This period of the year is always full of dreams and whishes. In this case, I am certain the model would work, but would Micosoft be rational and open?

Technorati Tags: Presence, Antecipate

Speaking of cluetards...

2006-12-13T14:35:00.000+01:00

Have you notice the drums roll and trumpeting around the latest Sametime interoperability announcement? I always find it entertaining to witness how incumbents can turn a failure to respond to their customers wishes into a world saving progress without even a blush!

At the end of the summer of 2004, I had the opportunity to see IBM in action at a workshop held by the Financial Service Instant Messaging Association on the subject of IM interoperability. FIMA had been worried very early on by the disparity of instant messaging protocols, both in the public and the enterprise IM space. So they set to give their least common denominator functional definition of interoperability, which when you think of it is not asking for the moon…
At the workshop, vendor presented their views, and it all went smoothly until the chair of the Jabber Software Foundation asked IBM why they wanted to support the still unfinished SIMPLE protocol as a federation protocol rather than XMPP which was already stable and widely used alongside Sametime in the financial industry.
Anyone either business savvy or a little familiar with Sametime's technical architecture would have though along the same lines. From an architecture standpoint, the multiplexers, community hubs and community server applications of sametime, with their permanent TCP links, can be functionally mapped one to one with XMPP client connectors, session managers and service components. From a business perspective, federating the existing large financial industry's Sametime islands with the expanding XMPP footprint would have help IBM keep an edge against the nascent Microsoft LCS expansion.
Instead, we were granted a flame from the IBM representative in favor of SIMPLE which was more typical of a Gorilla's behavior than a business representative:

If challenged by a younger or even by an outsider male, a silverback [Silverbacks are the strong, dominant troop leaders] will scream, beat his chest, break branches, bare his teeth, then charge forward.

In short, SIMPLE was the way to go, and everyone not endorsing it was stupid and doomed to fail. Well, two years after, IBM announced interoperability with XMPP, which instantaneously guaranties secure and controlled communication with any XMPP server, including those at Google. They also announced interoperability with AOL, but funnily enough they do not specify what protocol they use. You maybe interested to know that AOL offers both an LCS flavor of SIMPLE and XMPP to enterprises for federation with AIM. As there is no mention of interoperability with LCS in the Sametime announcement, it would be interesting to have a clearer insight on what they IBM is using for interconnecting with AOL. As to Yahoo!, well it is always a little difficult to have anything but a fuzzy statement from these guys. Anyway, the announcement said federation between Sametime and Yahoo messenger is on the "road map".

Ken Camp came up with a nice and illustrative contraction to apply to people unable to spot the appropriate answer to end-users' aspirations, cluetards… In this case, IBM is only different from the average by the size, just a large cluetard. If I were a financial Sametime customer, I would claim compensation for having been treated this way and left longing for so many years.
More importantly, this episode illustrates once again how large incumbent IT vendors are blind to real users' needs, when they are not in line with their core business. IBM business is in selling servers, not in providing communication between peoples. I find it amazing that a pure technical choice made by some ex-Ubique geek ended up depriving an important business community of an easy and beneficial way to conduct their business with small firms or other institutions.

Beyond this, Giacomo is in my opinion asking the right question: should we forget SIMPLE? In a perfect world, I would certainly answer positively. In the real world, it will take some time in view of the interests at stake. Having been involved in designing applications federating both protocols, I certainly have a unique perspective on the strength and weaknesses of each of them. From a technical standpoint, my only observation is that SIMPLE simply lacks the simplicity needed for a wide adoption.

Except the Microsoft LCS there is no SIMPLE based instant messaging and presence (IMP) application in service outside the telecom industry. Anybody having looked closely at the actual protocol used by LCS will agree that it's actual compliance with SIMPLE stops short after the first SERVICE packet. Microsoft has leaned the hard way that SIMPLE was not ready for IMP, and has been obliged to supplement the lack of the protocol with LCS own extensions. Such things as multi client instances, message sessions, contact lists management, preferences, multi user conferencing are notably absent from the specification and have partially been implemented by Microsoft using non-standard extensions.
From a user agent perspective, the closest to a "standard" SIMPLE client implementation is the Counterpath' eyebeam softphone and it XLite derivative. Their development team deserves the greatest respect for having incessantly been trying to accommodate the ever changing scope of XCAP, and the various contact lists management options that must be part of a "workable" SIMPLE solution. But while doing this, they had no time to automate the status change to "on the phone" when a SIP call was taking place…
From a standard stand point, those who have red the 2500 plus pages from the 3GPP describing the use of SIMPLE for presence are well aware that, for example, list services, XCAP and a stable definition of rich PIDF are on the critical path for delivering the service as expected by the IMS architecture. XCAP is probably the most blatant example of wheel re-invention in this industry, where the oversized ego of the author is holding back an entire industry. More importantly, if one look at the SIMPLE RFCs and drafts authors, one can quickly infer that the standardization process is done by a vendor led consortium. As I have said before, almost every vendor led consortium has failed to impose any long lived interoperability standard on the Internet. I am afraid SIMPLE is another one of them, and it is time to realize it…
Finally, there is the complexity of SIMPLE. It makes it difficult to grasp by the average application developer outside those versed in "voice over…". When adding together the rather rigid framework provided by SIMPLE and the vast differences in interpretations by various implementers, it makes this protocol look "elitist" when compared to XMPP. As I mentioned above, having designed and implemented converged systems supporting those two protocols simultaneously, I can vouch that any application programmer can grasp how XMPP works; the same is not true from SIMPLE.

As Ken put it, simplicity and elegance alway make winners and losers. Simplicity is unfortunately not the first quality of SIMPLE. As a result, it has not seen mainstream adoption by web application developers which are instead turning to XMPP. That said, SIMPLE will not go away easily in view of the heavy investments made by many cluetards. Unfortunately this state of affairs will help maintain the silo divide between the telecom and the internet worlds.

The term "elegance" finds its origin in the Latin "eligere" which also gave the derived term "election". In fashion as in real life, elegance implies making a choice. In the Sametime case, it was between remaining Incredibly Blind and Mediocre, or working at solving real end-users pain points. You can guess what choice was made…

Technorati Tags: XMPP, Jabber, SIP, Interoperability, Antecipate

Maps of every country unite!

2006-12-02T13:14:00.000+01:00

Some time ago, I was researching XMPP presence indicators that could be embedded into a web or blog page. This is how I came across Jobble, a Google maps and XMPP presence mashup. I knew of other similar services, such as Jabber World Map, Jabber Google Map and Talk Maps. They all provide the same kind of information: a map with the presence state representation of online XMPP users. For some reason, I prefer the way the Jobble site presents the information. But it is only a matter of taste.

As I was toying with these different services, it appeared to me that they were used by different demographics, which were themselves geographically concentrated. For example, Jobble, which is a Polish project, has a vast majority of subscribers from north-eastern Europe. The same applies to Jabber World Map which is coming from the Netherlands. Talk Maps has a slight majority of users in Europe, but overall users are thinly spread. Curiously, north-american users don't seem to fancy this kind of service…
My second observation was that those of my contacts using these services were scattered on several separate maps. I would have liked to have them on the same map instead. This is how I thought of federating XMPP maps.

Putting people on a map is a way to make them feel closer, and somehow participate in a feeling of community. But when these communities do not intersect, the chances to communicate and establish new relationships remain low. I have discussed earlier why a closed community would ultimately be less sticky than an open one, and looking carefully at these services shows they somehow act as closed communities. I think that the choice of registering to a particular map service must only be governed by the features that can be derived from the user presence, and not from the presence collection itself. For example, someone may prefer the way Jabber World Map show online users when the mouse hovers above a symbol, other the traditional point and click approach of Google Maps found in Talk Maps. Furthermore, someone may want to develop a similar service using Yahoo flash based maps, to be able to add some overlays.

Unfortunately, the ways these services are implemented today only lead to a walled garden result. Each service is built around its own data store and does not communicate with the rest of the world. Furthermore, they only allow static geo-location mapping, leaving out mobile devices or traveling users. Thinking of it, it is not that difficult to modify these services and turn them into distributed geo-location providers. The base features I would expect of such services are summarized bellow:

Single registration and management point. The options chosen for my geo-location information using a particular service may become available to other similar services without forcing me to register with each of them individually.
Static and dynamic geo-location data support. I want to be able to specify either static longitude and latitude values for a fixed workstation, or have the service pick up this information dynamically from a particular client.
Privacy and information propagation control. It may look strange to mention privacy amongst the expected features, as putting one's presence on a map is already revealing a lot. But I would expect the service to provide a way to control the propagation of these data outside the service through an appropriate combination of white and black lists.

Looking at possible implementation options, I believe we have to keep the current approach which exposes the service through a presence enabled bot. It has the immense advantage of being well understood by the average user.
As a first step, the bot would need to be modified to understand the Personal Eventing (PEP) extension notifications. This will cater for dynamic geo-location updates. As PEP implementation progress, the service will automatically get access to dynamic geo-location information as they are set on the end user device, and will be able to display it on the map along with the user's static data. From an end user standpoint, this would also simplify the fine grain tuning of which piece of information is made available to the service directly at the PEP level.
The bot could also be adapted to support PEP subscriptions. This would be appropriate in case the user's home server or the user profile does not allow an automatic subscription to PEP when someone subscribes to the user's presence information.
Finally, the service itself would have to expose a user geo-location node as specified by the publish/subscribe XMPP extension. It would not be necessary to implement a full fledged publish/subscribe service, but rather make the service understand only the appropriate subset dealing with the http://jabber.org/protocol/geoloc namespace. Another map service interested to get geo-location information would then subscribe to this node and receive any published modification.

<message from= "map.montague.net" to="map.capulet.com">
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node="n48ad4fj78zn38st734">
      <item id="a1s2d3f4g5h6bjeh936">
        <geoloc xmlns="http://jabber.org/protocol/geoloc" xml:lang="en">
          <country>Italy</country>
          <locality>Verona</locality>
          <lat>45.44</lat>
          <lon>10.996</lon>
        </geoloc>
      </item>
    </items>
  </event>
  <addresses xmlns="http://jabber.org/protocol/address">
    <address type="replyto" jid="romeo@montague.net/orchard"/>
  </addresses>
</message>

Another possible approach would be to make the service itself support presence subscriptions and have the geo-location information implemented in a PEP node. This way the relationship between two map services would be entirely presence driven, enabling added control through presence states. For example, there would not be notification toward a service which does not appear available. This is important in period of maintenance, or can be used as a way to throttle down heavy traffic. Presence would also be used to propagate end user's availability states.

<presence from= "map.montague.net" to="map.capulet.com">
  <show>away</show>
  <addresses xmlns='http://jabber.org/protocol/address'>
    <address type="replyto" jid="romeo@montague.net/orchard">
  </addresses>
</presence>

The end result would be a distributed geo-location information aggregation that could be leveraged through a standard and open protocol. Several local aggregators could be built by geographically close communities, but see their reach extended to the Internet as a whole because of the distributed design. From an end user stand point, there is not lock in, as it is possible to choose a service on the feature set offered and move to another service implementation without being forced to use yet another address handle. The combination of service based and PEP based filters would ensure a good level of privacy control. And in the end my presence and geo-location information as seen by Jobble will be reflected on as Jabber World Map, Jabber Google Map and Talk Maps without forcing me to add a bot in my contact list for each different service.

Technorati Tags: XMPP, Jabber, Presence, Geo Location, Publish subscribe, Social network, Antecipate

The six oldest new ideas in chat…

2006-11-30T13:51:00.000+01:00

Since I came across this post, I was looking for the proper illustration before coming back to it. In the end, the simplest and first impression is always the right one: this author does not have the slightest clue of what he is talking about…

First of all, he starts by being confused by the subtle difference between "chat" and "instant messaging". In effect, most of the "exemplifying" services or product he mentions are doing with instant messaging, and some of them offers multi user chat facilities. But instant messaging is not really news.

Interoperability. Ever since the invention of the telephone, interoperability has been the single requirement for any mediated communication system. In short we cannot decently consider this to be a new idea. Because of the early calcification forming into the innovative region of most corporate executives' brain, we unfortunately face a walled garden landscape for instant messaging (amongst other things). So suddenly discovering that "clearly, open standards are here to stay" is not properly visionary. Well as they say in China, "when the wise man point to the moon, the fool only sees the finger".
As a passing remark, unless I am mistaking, Trillian, Gaim, Adium and Miranda are multi protocol instant messaging client applications, not "services".

In-Browser Chat. This one is misleading because of the confusion between chat and instant messaging. But a simple search on the term chat will bring back 551,000,000 results which tends to indicate that chat has been in the news for quite some time. And when you carefully look at the results, you will find that many point to in-browser chat for so called "adults" services. But isn't this the oldest business in the world?
There are a number of browser based instant messaging clients which are trying to solve the interoperability issues mentioned above. For the same reasons that lead to the ineluctable disappearance of communication silos, only those services that rely on open protocols will remain. At that point in time, the end user will have the choice of installing a standard based client application on its workstation or use the same application hosted at a provider. The debate between hosted and non-hosted application has been part of the IT landscape ever since its beginning. This is not new either.

Location Based Chat. Geo location services have existed in mobile phone services since the early days of GSM. Before the web 1.0 bubble, some vendors were even touting geo location as "killer application". And it is still part of several mobile application services trying to bring contextual search to road warriors.
As I explained earlier, geo location can participate in bringing a sensation of "place" into mediated communication. But initial research on the subject dates back to the mid nineties. It is fair to say that most of the research was concerned about "virtual reality" worlds at the time. Obviously, instant messaging was not yet considered mainstream. This simply re-enforce the length of the road leading from ideas to their applications in different domains, but this has always been the case.

Flexible Identities. A quick look at this post will convince you that multiple personae have one of the longest research histories in the context of the Internet. You will also notice that there is a subtle distinction between "multiple personae" and "multiple facets" of one's identity. The same as between Doctor Jekyll and Mister Hide…
As a remark, the provided examples only implement precepts from the now defunct Presence and Availability Management forum on how granular presence was to be used to manage communication address handles, and when thinking of it, all the call forwarding features available in a PBX were already a way to "separate your private and professional faces". After ten years of "converged communication" talks, applying the same principles to instant messaging should not come as a real surprise.

Contextual Chat. In this case we are really talking about chat. This section presents a blurred mix of two different concepts. On one end there is the chat room client who can be embedded on different web pages, such as blog posts, and provide a fixed context for discussion. On the other end we have the "virtual presence" clients as browser's add-in which will work on any web page. The idea of being instantly aware of other users reading the same web page emerged early in the history of the Web. Implementation projects appeared in the fist half of the nineties with the advent of Virtual Places and other co-browsing initiatives. Ten to fifteen years on the Internet time scale are more like a century to me.

Rich Media Chat. As the author puts it "web cams and microphones have been on the web for a while", and it is only the commoditization of broadband network access and computing power that made "rich media", read internet audio and video, accessible to the mass. Already in the early days of video-conferencing, when only ISDN and leased lines were available, several systems were offering in-band instant messaging and even document sharing. Once again the idea dates back fifteen years. As for the previous section, speaking of novelty is not appropriate. That said, the trend to combine audio to instant messaging is natural as it mimic a real world behavior. The challenge will be to provide a seamless experience moving from one medium to the other across different devices.

The Internet has an immense magnifying power. It even allows us to quickly search a vast knowledge repository for information that would be relevant to make a post valuable. But using a flashy title is still far easier than providing relevant content: you only need to utter six words instead of a few hundred. Unfortunately the lazy approach based on making noise has been around since the beginning of time.

Technorati Tags: XMPP, Jabber, Interoperability, Instant messaging, Antecipate

The speech act of replying to a question

2006-11-30T10:21:00.000+01:00

It is somewhat interesting to note that the Google Search result for the definition of "answer" gives a large majority of answers related to the legal practice. For a company so certain it can decrypt the vast complexity of human nature by using algorithms, that must the finding must have been devastating! From then on, the reaction to the stimulus was ineluctable. An automatic correlation with the recent increase of the number of legal proceedings against Google was obvious and could only lead to a single answer: bring down Google Answers…

Although the announcement eulogizes the innovative nature of the service, it did not protect it from down to earth consideration: it was not making money. Many have been and still are questioning the company's pretence to innovation. Google is no different than any other large incumbent, it just chose another moto: the "non evil" company. But these are just words. Google is master at coercing and, as many businesses, will use its power to smooth out its way to domination.

More simply, Google is not about people: its business model is only to become the largest advertising agency ever. Advertising only works by flattering basic instincts, lowering critics barriers and feeding distorted and subjective information. No wonder there is no space for real human answers in this context…

XMPP.fm

2006-11-28T13:09:00.000+01:00

The latest announcement of an XMPP based tool to support music fans communities got me thinking how easy this can be implemented by putting together the proper XEPs. Let us consider how to implement an XMPP internet music radio similar to Last.fm. Obviously we would want to put some "social" focus into it. So the scope is simple:

Broadcast music to anyone joining the service, even on a temporary basis.
Provide a music recommendation system.
Provide discussion spaces amongst listeners.

From a protocol standpoint, the basic extensions we would need to provide this type of service are MUC for the community part, and PEP for the announcement part, obviously complemented by the user tune extension.

A very straightforward implementation route would be to create a presence enabled service to which any users could subscribe. The service will expose a number of "stations" implemented as MUC rooms corresponding to musical subjects of interest for the en users. So you may have rooms such as acoustic, alternative, ambiance, classical, dance, dark, experimental, folk, funk, groove, hip-hop, instrumental, jazz, lounge, metal, pop, punk, rap, reggae, rock, ska, techno, world, [add your own genre here]… To add the required "social" trend, one can imagine a system where users are able to tag and rate the music pieces and rooms are automatically created and added from these user preferences.

…kind of a lite social network system, featuring chat and commenting throughout…

The service "identity" is provided through some kind of DJ bot. End users subscribe to the presence of the bot, and are also automatically subscribed to the bot's personal eventing notifications. The bot also request to be subscribed to the user's tune events. Whenever a user come online, then it will receive XEP-0118 notifications from the bot describing what is currently playing in each active room. Obviously each notification will be augmented to include the URI of the corresponding room, to allow creating a "stations" list for the user to choose from.

Tuning to a station boils down to joining the associated MUC room, providing instant conversation between music lovers with similar tastes. These MUC room are augmented to allow direct presence subscription in the case end users prefer to tune directly to specific musical genre. Every "station" has its own DJ bot to which participants in the room can make suggestion as to the next piece of music to be broadcasted. The DJ bot is also in charge of notifying the room participants of the currently playing piece. It does it by simply posting notification to the room and relies on the standard MUC mechanisms to take over the distribution. This has the advantage of having the "station" past program automatically handled through the room history. The notification will be extended with the information about the physical connection URI in order to enable listening to the current track using the user’s workstation features.

Scrobbling tracks is directly available when the user set's its own user tune state. The notification is sent to the service DJ bot for collection and update of the appropriate statistics.

Additional “social” features could be implemented at each “station” level through the appropriate use of mood and activity publications and notifications. If participants are also able to publish their current room information through XEP-0194, the service could be enriched to provide what Wikipedia describes as:

The most-used community feature within Last.fm is the formation of user groups between users with something in common (for example, membership of another internet forum). Last.fm will generate a group profile similar to the users' profiles, showing an amalgamated set of data and charting the group's overall tastes.

I have already mentioned the lack of interest by the web 2.0 crowd in leveraging XMPP killer features. As one can see from the above quick jotting down, many of the puzzle pieces are readily available. In addition, they can be used from standard XMPP clients supporting MUC and PEP, which will be mainstream this year end. Those wanting to add all the bells and whistle of a multimedia UI can do so by building a flash based client with embedded audio and video players, and they will be ready to compete in the Media 2.0 broadcasting space without much technology investment. XMPP has reached a stage where a large number of applications can be built from its existing features set. It is still just a matter of imagination and creativity…

Technorati Tags: XMPP, Jabber, Chat, Flash, Publish subscribe, Social network, Antecipate

XMPP rocks...

2006-11-28T01:36:00.000+01:00

I used to smile when Peter was writing this kind of phrase, but this time it is real ...

“The Virtual Ticket Media Player Chat Room is written and operated under Extensible Messaging and Presence Protocol (XMPP) standards. This means that other users will be able to use their existing messaging software (Trillian, GTalk, etc…) to connect, authenticate, and log in to the Artist’s chatroom. Currently, the built-in Virtual Ticket Media Player chat interface is the only public way to enter the Artist’s chatroom though support for other clients is planned.”

A great example of what can be achieved by combining MUC and multimedia

Technorati Tags: XMPP, Jabber, Antecipate

Sensing activities in MUC

2006-11-27T18:59:00.000+01:00

I have discussed before why conversation spaces are not places themselves, but rather for people to make places in them. In physical places as well as virtual ones, adaptation and appropriation of the associated technology by users is a critical element in the emergence of a sense of place and appropriate behavior. In short, the sense of place cannot be inherent in the system itself.

Within a place, social navigation is navigation through information collections on the basis of information derived from the activity of others. In the real world, we act where we are. We talk to people around us, because voices can only be heard at a short distance; we get closer to things to view them clearly. Understanding proximity helps us relate people to activities and to each other. When we see a group gathered around a meeting table, we understand something about this peoples' activity, and we know that another person standing off to one side is likely to be less involved.

Just like in real life, place aware presence systems should allow users to move to areas where others are clustered, to join the crowd and see what's going on. Since actions and interactions fall off with distance, so distance can be used to partition activities and the extent of interaction. I have described here how the use of "social proxies" can be used as abstract artifact to induce additional social information. Amongst the "social proxies" that have been studied, I find the Bable experiments particularly interesting as it could be applied to multi user conversations, such as the MUC rooms available on many XMPP servers. The proxy's role is to provide cues about the presence and activity of participants in the current conversation. It is graphically represented by two concentric circles similar to the drawing herewith. The outer circle symbolizes the conversation room border, the inner circle the conversation subject. Every participant is represented by a colored dot. The way it works is that participants in a particular room are shown within the proxy outer circle. People in other rooms are positioned outside the circle. When people are active in the conversation, meaning they either "talk" or "listen", then their dots move towards the inner circle, and then gradually drift back out to the edge when their activity decreases. What is interesting is the way test users have reported their experience of using this type of proxy:

…our users report the social proxy is engaging and informative. They speak of seeing who is "in the room," noticing a crowd "gathering" or "dispersing," and seeing that people are "paying attention" to what they say (when other dots move into the center of the proxy after they post).

On the practical implementation side, XMPP provides a number of extensions that can be put to use to enhance existing MUC implementations to support this type of social proxy. Beyond the specificity of the social proxy, the expected enhancement falls under what I have been writing about as presence feedback.

XEP-0085 associated with message stanzas moving averages over time calculated at the MUC room level could provide sensible indications about the "talking" activity of every participant. A "listening" activity indication could be derived from the automatic presence status generated by the client.
XEP-0163 could be used at the MUC room level to notify the MUC clients of each participant's dots relative position changes to be displayed on the client interface. If we limit the proxy geometry to a Cartesian representation, we could easily derive an appropriate format for the associated data similar to the Geo Location XEP.
Other MUC rooms' global activity could also be provided to further accentuate the overall places context. Obviously, the notion of proximity could also be put to use to induce the notion of semantically related room discussion contexts.

In the end, I believe it is not overly difficult to assemble all these XMPP extensions together in a MUC implementation and, as a result, give a better sense of other people's presence and the ongoing awareness of activity into the conversation space. All in all it would be an interesting step toward better structuring our activity in the rooms, and better integrating communication and collaboration.

Technorati Tags: XMPP, Jabber, Conversation space, Presence, Antecipate

Visibility, Awareness, and Accountability

2006-11-26T19:30:00.000+01:00

I have already presented the concept of "social translucence" while discussing the benefit of adding "place" based information to presence for a better regulation of mediated communications. A "socially translucent" system enhances two important dimensions of communications. First, by making social information visible it enables participants to be aware of what is happening, and to be held accountable for their actions as a consequence of public knowledge of that awareness. Second, the fact that the real world is translucent to social information, and that people have a sophisticated understanding of the consequences of the visibility of their social interactions helps structuring interactions in a mediated communication.

While the "social translucence" perspective is unique, it is not the only concept to be concerned with making the activities of communication systems' users visible to others. Since ten years, a considerable research work has been targeted at video-mediated communication (Finn et al., 1997), and has led to the concept of "awareness". A number of researchers have constructed systems attempting in various ways to provide cues about the presence and activity of their users (Benford et al., 1994). These researches have highlighted three design approaches to representing social cues in a digital system: the realist, the mimetic, and the abstract.

The realist approach tries to project social information from the physical domain into or through the digital domain. This work is exemplified in teleconferencing systems and media space research.
The mimetic approach tries to reproduce social cues from the real world as literally as possible in the digital domain. The mimetic approach is exemplified by graphical games and virtual reality systems. It uses virtual environments and avatars to mimic the real world.
The abstract approach involves portraying social information in ways that are not closely tied to their physical analogs. It could uses abstract sonic cues to indicate social activity, or abstract visual representations. This approach also includes the use of text or simple graphics to convey social information.

Large deployment and adoption of systems based on the realist or mimetic approaches have faced substantial pragmatic hurdles, such as their cost, the required infrastructure, and the constraints of users support. On the other hand, I believe that the abstract approach has not received sufficient attention, particularly with respect to graphical representations. Text and simple graphics have many powerful characteristics: they are easy to produce and manipulate; they persist over time, leaving interpretable traces; and they enable the use of technologies such as search and visualization engines. In this last category we find "social proxies" such as those depicted here.

A social proxy is an abstract dynamic graphical representation that portrays socially salient information about the presence and activities of a group of people participating in an online interaction. It is one technique for providing online, multi-user systems with some of the cues so prevalent in the face to face world. Social proxies are intended to be visible to all those portrayed in them, thus providing a common ground from which users can draw inferences about other individuals, or the about the group as a whole.

Typically, a social proxy shows participants in a particular "place", as well as some of their activities in that "place". The choice of which aspects of activity are visible, and which remain private, depend on the particular context. Social proxies have four basic characteristics:

A social proxy typically consists of two components: a large geometric shape with an inside and an outside that represent the online "place", and much smaller shapes positioned relative to the larger shape that represent participants.
The presence and activities of participants in an online "place" are represented by the location and movement of the smaller shapes relative to the larger one. The relationships and movements of the visual elements have a metaphoric correspondence to the position and movement of peoples in a similar face-to-face situation.
Social proxies are public representations, and everyone looking at a social proxy for a given "place" sees the same thing. It is not possible for participants to customize their views of a social proxy. This is important because I know that if I see something in the social proxy all other participants can see it as well. This is what supports mutual awareness and accountability.
Social proxies are represented from a third-person perspective. Looking at a social proxy, every participant sees itself represented in it in the same way other participants are represented. This enables learning. A participant can see how its actions are reflected in its personal representation, and thus begin to make inferences about the activities of others.

The shared nature of a “social proxy” is critical. The knowledge that activity depicted in the social proxy is visible to all participants makes it “public”, and transforms it into a resource for the paticipants. It is this visibility that supports people accountability for their actions, and underlies the social phenomena, such as feelings of obligation, peer pressure, and imitation, that enable coherence in groups interactions.

On the Internet we are socially blind, and our attempts to communicate are often awkward. Even when others are clearly present, as in a chat room or on a conference call, it is difficult to see who is present, who is paying attention, or who wishes to speak. Things that require little effort in real world "places", such as taking turns when speaking; noticing when someone has a question; seeing who is responding to whom, require a lot of effort in online "places", when they at all are possible. I think introducing "social proxies" in widely used presence enabled applications, such as IM or VoIP clients, would allow us to progress on the way of a better sensitivity to the actions and interactions of those around us in virtual "places".

Technorati Tags: Conversation space, Presence, Instant messaging, Social network, Antecipate

Presence and going places

2006-11-26T01:11:00.000+01:00

Mike Gotta has jotted down a series of notes about his trend of thoughts regarding presence technologies. In my opinion, his segmenting of the subject strongly reflects the constraints of an analyst work, but he nevertheless brings up many interesting points. I like in particular the way he widens up the scope of the reflection beyond current implementations

... food for thought and for consideration as to how some of these items relate to assumptions currently made around presence systems. How many assumptions based on instant messaging, IP telephony and so on will get in the way of a more expansive view of presence?

From his points, I would like to focus on presence relations to "location", "environment", "activity" and "role", what is often refered to as parts of a context. In that respect, because of their strong relationship to the physical reality, the use of spatial metaphors and spatial organization to model context have been favored by many mediated communication and collaboration systems. I believe this approach does not properly capture the complexity of real human social interactions. In real life, we are located in "space", but we act in "places". If the structure of a world is spatial, by comparison a “place” is a space invested with social meaning, such as behavioral appropriateness or cultural expectations. Furthermore "places" are valued "spaces". The distinction is like between house and home: a house is where we shelter, but a home is where we live. In order to get contextualy closer to the complexity of social communications, integrating “place” based information would greatly improve presence technologies.

Presence technologies make applications augments physical reality rather than replaces physical reality. Current implementations fall short in adapting to the vast variety of social communications contexts any human being is experiencing in real life. For example, the nature of relations and interactions with one's friends and family differs significantly from the nature of relations and interactions in the workplace. Even these simple differences are only superficially addressed by today's presence enabled applications. As a matter of illustration, we can cite:

The way of establishing trusted presence relations scales poorly. To establish individual full trust between 10 persons, 10×9/2=45 bilateral agreements need to be established. Trust groups would scale much better and be easier to manage.
The availability status does not provide much added value. Many community systems provide a list of who is on to the community website, using a group-based trust model where presence information not only indicates "who is online" but also "who is here". This model may work well when using a community’s website as primary shared resource. However, many groups and communities in workplaces often use a variety of shared resources. In such cases, for example when co-workers are always online at the same time, more detailed presence information than just online/offline status is needed.
The trust model is very crude. Either one establishes a trust relation and can always observe other's presence information, or one does not establish a trust relation, in which case one can never other's presence information and cannot engage in conversations. This might not be problematic when dealing with friends and family, with whom you expect to resolve unwanted interruptions easily. It becomes a problem when dealing with a larger set of co-workers in a multi-project environment.

Presence technologies need to be augmented to provide information not only about people but also about “places”. Unlike what is currently offered in IM and VoIP applications, more advanced presence mechanisms must allow exchange of information only with a certain subset of people, not always but sometimes only, depending on real-time context information that can be derived from the virtual or real “places” people visit. Today, ordinary presence systems only give answers about person oriented questions:

Who is online, or is this person online?
What is this person doing?

Advanced presence systems will have to provide answers and notifications about “place” oriented questions, such as:

Who is here?
Who is near?
Where is that person?
What is that person doing there?

It happens these questions can be answered by combining different scoped attributes of presence infomation, including the trust relation between parties, their real or virtual locations, activities at these locations and presence and awareness scopes.

Trust scope. Some presence systems allow anyone who has access to a presence server to see presence information of others, other systems are more restrictive. The establishment of trust is distinguished by four model aspects:

Opt-in / opt-out / managed: In an opt-in trust model, others can only see presence information if you explicitly give them permission. In an opt-out model, others can see presence information, unless you explicitly denied them permission. In a managed model, a third party instead of the users determines who can see presence information.
Individual / group: In a individual trust model, each person rights to presence information are managed separately. In a group trust model, rights to see presence information are managed for an entire group.
Reciprocal / non-reciprocal: In a reciprocal trust model, if A has the rights to presence information of B, then B also have the rights to the presence information of A. In a non-reciprocal trust model, this may not be the case.
Permanent / blockable / contextual: In a permanent trust model, presence information is available as long as the rights to do so exist. In a blockable trust model, presence information can temporarily be denied. If the rights to presence information are based on location or place the trust model is contextual.

Location scope and virtual distance. When users browse the web, edit files from a shared storage, or read or post in blogs, they are present at a "location" in cyberspace. That said, many characteristics of physical space, such as being aware of someone's presence, and being able to initiate contact and communicate with that person, do not necessarily exists in the cyberspace.
Location information is expressed by coordinates, but in cyberspace unlike in the real world, users can be at multiple coordinates simultaneously. Place-based presence systems need to answer the question "Who is near?", have to calculate virtual distance between these coordinates. Virtual distance is then used to determine who can and who cannot be seen. To calculate virtual distance, presence location coordinates need to be laid out in a space, such as topology, virtual world or any directed graph. In place-based presence systems, location information constitutes a primary form of presence information. Not only the fact that someone is online somewhere in cyberspace, but also which resource that person is accessing provides presence information that can be made available to trusted parties.

Presence scope. A presence scope specifies the maximum virtual distance at which a trusted party can watch presence information. One may use multiple presence scopes, e.g., "people on the same website can see me, but cannot see the page I am on" and "people on the same web page can see if I am focusing on that page".

Awareness Scope. An awareness scope specifies the maximum virtual distance at which a user wants to get notified of presence information of trusting parties. One may use multiple awareness scopes, e.g., "are there people with me on the same web page?" and "are people with me on the same web page focusing on the page?".

Activity scope. What a user is doing at a location is also presence information. For example, in addition to browsing a web page, this may involve whether the user is actually focusing on this page or not , whether the user is editing this page or not.

Ultimately, by relaying “place” based information, presence technologies will enable three important building blocks of social interaction-- visibility, awareness, and accountability-and thus become "socially translucent" systems. We can illustrate a "socially translucent" system by the following example. Consider a door with a design problem, which is likely to slam into anyone about to enter from the other direction when opened quickly. An attempt to fix this problem would be to place a "Please open slowly" sign on the door. As one might guess, the sign is not a particularly effective solution. But we could also put a glass window in the door. As people approach the door they see whether anyone is on the other side and, if so, they modulate their actions appropriately. The sign is no longer required. While this solution works, it is useful to examine the reasons for the effectiveness of the glass window:

Firstly, the glass window makes visible socially significant information. As humans, we notice and react to movement and human faces and figures more quickly than we notice and interpret a printed sign.
Secondly, the glass window supports awareness. One does not open the door quickly because one knows that someone is on the other side. Our social rules come into play to govern our actions, as we have been raised not to slam doors into other people.
Lastly, there is another subtler reason. Even if one does not care about hurting others, one will nevertheless open the door slowly because one knows that the other knows that one knows it is there, and therefore one will be held accountable for its actions. While awareness and accountability usually occur together in the physical world, they do not necessarily in a virtual context. It is through such individual feelings of accountability that norms, rules, and customs become effective social control mechanisms.

Note that "social translucence" is not only about acting according to social rules, but more about facilitating different types of communication and collaboration. Using presence information it is today possible to observe that another party is likely to be available for communication. In return for giving up some privacy, the other party expects to be contacted at suitable moments, can screen incoming messages, can plausibly deny being present by not responding or responding later, or simply by initiating the conversation at a time of its choosing. With "socially translucent" presence technologies it becomes easier for users to have coherent discussions, to observe and imitate others' actions, to engage in peer pressure, to create, notice, and conform to social conventions.

Technorati Tags: Conversation space, Presence, Instant messaging, Social network, Antecipate

Jingling call control

2006-11-22T17:13:00.000+01:00

Third party call control is what makes applications such as "click-to-call" possible. Although I will not qualify "click-to-call" of killer application, its potential in traditional commerce or support applications is undeniable. In essence, third party call control is a must have when the communication sessions are managed by just more than individuals.

Although until recently third party call control was the guarded property of large telecom vendors, a new breed of call control gateway has made its appearance. These devices bridge Microsoft's LCS world with the open source world of Asterisk, and provide a way for the Office communicator client to control the open source IPBX:

Use Office Communicator as a soft-phone to place calls, deflect calls, forward calls through Asterisk.
Receive incoming call notifications, see who is calling and reroute to an alternate number.

Obviously I do not feel this kind of device important because of what they do for the Microsoft closed products, but rather because they do it through the use of a standard protocol. Office Communicator has a built in support for the ECMA-323 standard, which is also known as CSTA XML. CSTA in its binary disguise has been around telecom vendor's equipment for a while. But I am ready to bet that its XML version will gain more and more traction as it allows a much easier and quicker integration between communication equipments and business applications.

In the context of Jingle, supporting different forms of call control is mandatory if the protocol is to see adoption beyond the narrow context of peer-to-peer direct communications. And I believe that looking to integrate CSTA XML and Jingle is the way to go.

Technorati Tags: XMPP, Jingle, Call control, IPBX, Phone system, Antecipate

Down with the phone number tyranny

2006-11-22T15:59:00.000+01:00

Martin Geddes is the last amongst a long line of heroes before him to have a whack at killing the phone company. The phone company is like the fabulous Hydra of Lerna. For each of its head heads that is decapitated, another one or even two more spring forth. In addition, like the Hydra beast which is half snake, the phone company has a very long tail…

Besides the underlying saga, this post also join in the growing chorus advocating what Ken Camp summarize as

… presence and availability, or context, or whatever they become as facets of our digital identity and persona will be a huge piece of the evolution of unified communications.

Martin speaks of context as a driver for communication. I would say that context is the only driver of communication. We never communicate outside of a context, and whatever media we use must be able to take the context into account. But this has nothing to do with the technical context Martin describes. His context is just the mere legacy of the antiquated operating systems and user interface in use today. The context driving the communication is a temporal cross reference intersecting several social groups and encompassing one or several spatial environments. The post is interesting as it goes on trying to develop on concepts tightly related to presence technologies.

I like the way he describes how Outlook may look like if it were "socially" enabled, but I don't think he has grasped the full spread of presence technologies in upcoming communication systems. Describing an "address book" the way he does shows he simply did not take into account that the actual communication context is in effect part of one's own presence. So tomorrow's "address book" should only show what is relevant in this context.
There is another point where the post slightly misses the target. Or maybe this is a matter of wording. When talking of "collaborative" I am more inclined to use it in regards to inter-individuals collaboration, whereas Martin seems to emphasize the inter-applications collaboration. Beyond this semantic digression, I have previously described my frustration in front of current user interfaces, and this has since been further developed by Giacomo Vacca when he also deplores the crude state of these interfaces and says

It's not about how presence technologies provide information on users' availability, but rather how much presence information can be truly dynamic and reflect users' habits and personalities.

To illustrate my point, let's go back to the phone communication. The success of the phone lies in its ability to mediate the most important mean of communication common to any human being: voice. And voice has the intrinsic capability to convey intonations as well as articulated semantic meaning. As such, a voice communication system providing a decent sound quality will compete on fair ground with face-to-face communications where only sound is available. This quality makes the phone system unique, as it introduce almost no perturbation in the medium. And this quality also makes the phone system’s success. Every other means of communication introduce much higher perturbations in the medium.

I believe the phone is inexorably moving toward a wireless mobile device. This is a no return journey, and in a few years we won't see any fixed phone left. Hopefully, at the same time, the phone device interface would have evolved well beyond using

a touch tone keypad that was the ultimate invention in the early sixties
a display trying to simulate a miniature windowing system that became common in the early eighties.

Just look at all these poor mobile phone victims running in every airports' corridors, bent forward, pulling their roller bags with one hand while furiously thumb hammering their mobile phone with the other. Don't you feel they look strangely like the common representation of our Neanderthal cousins on the human evolution charts?

To conclude, I agree with Martin that we need to have a more integrated experience when we communicate, for the simple reason that technology should get out of the way. But, unfortunately, every example he gives still bears a strong influence from today's (or rather yesterday's) devices limitations. The most important of it being the use of phone numbers. The current phone devices are so closely associated with numbers that they are de-facto unfriendly to any other means of communication found on the Internet. A keyboard is already unfriendly, but a keyboard where you have to press three times the same key to obtain a single character is hundred times more unfriendly. We are so used to this approach for voice calls that we seem unable to think outside this limitation. See how Martin only describes "address books" as repertories for phone numbers…

Until the two words "phone" and "number" have been taken far apart, I believe we will unfortunately still see a lot of the phone company, both inside peoples’ minds and outside.

Technorati Tags: Presence, Conversation space, Phone number, Antecipate

Presence is irrational by nature

2006-11-18T20:54:00.000+01:00

Technologies are rational by design, and they tend to rationalize human activity when used. I came across an interesting reading (Luhmann, 1993, 1995) which emphasized the over simplification often introduced by technology. I think this is particularly true in complex human related applications, such as those found in mediated communications.

The flipside of technological simplification is loss of flexibility and contingent response that have to be re-instituted through artificial mechanisms. Technological sequences cannot handle (i.e. absorb, ignore, forget or dissimulate) unforeseen incidents at the level on which they operate, even though technologists currently attempt to construct systems that respond to emergent events on the basis of learning from experience (i.e. neural networks). Such simple behavioral characteristics as forgetfulness, dissimulation and indifference, that we often assume to be part and parcel of the limitations of humans, play an extremely important and adaptive role under conditions of emergence, complexity and unpredictability.

Human communications and interactions are neither rational nor designed. Furthermore, temporal regularity is important in human experience. Communication technologies create perturbations in the regularity of time that characterizes a life made of personal habits and social routines. Habits and routines are more than repetition. They are often unique and spontaneous human experiences, where each repetition is different from the last.
By comparison, immediacy and access, as well as the constant flow of information, command that we attend to whatever is nearest and most urgent. Doing so, we lose a line of continuity to a dashed line of distraction. In the end, we pay attention, but in spurts of sameness that contribute little to a healthy experience.

The adaptation between the technical and the human takes place at what is called the "interface." In the case of communication, this not just a user interface, but also a social interface. It is social because it mediates communication while facilitating the exchange of interpersonal cues and acknowledgments.

Because communication and presence technologies can stretch our relationships across time and space, they produce proximities involving rhythms of interaction, coordination of activity, ways of communicating, and ways of offering and protecting our availability. They do it creating kind of virtual proximities in which we become "equidistant" to one another. Unlike physical proximity, temporal proximity can be described as having qualities of speed, duration, acceleration, rhythm, and synchronization. Amongst the major challenges for communication and presence technologies we will find

respect for habits and social routines without reducing them to simple functional repetitions,
seemless flexibility and adaptability of user interaction,
mediation of rythms and time, in complement of space, to induce a more human impression of proximity.

Today's communication and presence technologies’ interfaces often create a recurring sameness. The functions codified in the technologies reproduce the same abstracted operation and the same simplified representation with each repetition. This functional repetition displaces the spontaneity of social tradition. And we begin to think that repetition itself is dull, when it is the technical procedure implementation that is dull. Just look at a mobile phone to get a sense of what I am driving at…

Technorati Tags: Presence, Social network, Antecipate

Streamlining remote probes

2006-11-16T16:24:00.000+01:00

I wanted to finalize my original topic on improving XMPP presence handling model for subscribers hosted on distributed home servers by looking at presence probes.
XMPP differs from presence protocols such as SIP/SIMPLE by using persistent presence subscriptions, instead of transient subscriptions to be renewed for every session. In this model, an XMPP client publishes its presence states variations to its home server, which in turn generate the appropriate presence notifications.
Furthermore, an XMPP presence server is only responsible, and above all knowledgeable, of its own user's constituency.

When a user want to initiate a presence enabled session, it publishes an initial presence after login. This is intercepted by its home server, which is in charge of

Responding to the client with the initial known presence state of every watched contact,
Notifying every contact subscribed to receive the user's presence.

The home server then triggers two processes:

A user's presence notification to all the watchers of its presence state,
A probe of each user's subscriptions to receive the contacts' presence states.

When every contact in a user's buddy list is co-located on the same home server, the server has a complete view of each contact's presence state, and using a probe stanza is not necessary. But if the contact resides on a remote server, a probe stanza is sent to that server to trigger a presence state stanza in return. Mridul rightly point out that the current specification leaves open the possibility for a server to cache remote contacts presence states and derive initial presence for additional instances of these contacts from cache. I believe the specification must avoid remote presence state caching. The probing mechanism is a guarantee for the home server to always have the latest initial presence state of remote users.

I can now come back to the early concern of minimizing the network traffic generated by presence handling when subscribers are hosted on distributed home servers. It is to be noted once again that the two processes of notifying all watchers and probing to receive contacts' presence states are asymmetrical. I have shown previously how notifications could be optimized by using transient remote users' lists. Conversely, probing multiple contacts' presence states is a one time operation.
XMPP requires that probes be sent to a global URI (bare JID). In my opinion, to the contrary of notifications, the expected gain of grouping several JIDs in a single stanza are more limited. Leveraging XEP-0033 Extended Stanza Addressing to group JIDs in a single stanza may result in slight traffic improvement if the number of remote contacts located on a single server is important. But for a limited number of remote contacts, the gain will certainly be marginal, so the complexity of implementing this kind of mechanism should be carefully weighted against the actual traffic gain.

An illustration of this mechanism is given bellow, assuming the multi-probe support has previously been discovered through XEP-0030:

<presence to="prober.denmark.lit" from="horatio@denmark.net/palace" type="probe">
  <addresses xmlns='http://jabber.org/protocol/address'> 
    <address type="to" jid="rosencrantz@denmark.lit"/>   
    <address type="to" jid="guildenstern@denmark.lit"/>          
  </addresses>
</presence>
<presence to="horatio@denmark.net/palace" from="rosencrantz@denmark.lit/on-the-road"/>  
<presence to="horatio@denmark.net/palace" from="guildenstern@denmark.lit/motel"/>

It is rather obvious that the overhead of discovering the support and using multiple addresses in a single stanza will offset the gain when contacts are spread up few at a time amongst many servers. That said, if a significant number of contacts are located on a remote server, the mechanism may prove valuable, not primarily because of the traffic reduction, but rather because all the probe targets are delivered in one single stanza. For the remote server it will generally be more efficient to process a series of JIDs in a single transaction without context switching, rather than processing several atomic stanzas each in its own transaction. I most other cases, the added complexity may not be worth implementing.

Technorati Tags: XMPP, Jabber, Presence, Antecipate

Presence calls out attention

2006-11-14T20:16:00.000+01:00

Every new piece of information put on the web becomes available to millions, almost instantaneously. Drawing a parallel with material goods, information production can be virtually infinite, and consequently, be in oversupply. Around ten years ago several definitions started appearing for what is now known as the "attention economy". The main concept was that over abundant information could only get value from the attention anyone of us was willing to devote to specific pieces of information.

To get attention you must emit what is technically identifiable as information; likewise for information to be of any value, it must receive attention. Therefore an information technology is also an attention technology, or in other words, a transfer of information is only completed when there is also a transfer of attention proceeding in the opposite direction.

In economy, property is the ownership of wealth. If attention has become a new kind of wealth, then one gain property whenever one attracts and holds it. One attracts attention by making oneself, and whatever one wants attention for, as visible as possible. Thus one holds best onto this form of property by being most open. In fact, this property is in the minds of one's beholders, and there needs to be as many minds as possible.
If one is good enough at attracting attention, it may create a temporary "enslavement", where those giving attention turn over control of a large part of their mind and even body. Attracting attention also means acquiring recognition, identity, and meaning in the eyes of those around. One's store of attention can sustain spirit, mind and body, in just about any form.
At the same time, those paying attention will also want to get attention for themselves by quoting, citing, criticizing, parodying, gossiping about, or referring to an attention grabber as if a star. In the extreme case which govern fans relationships to their stars, giving attention will take multiple forms such as listening to them, heeding what they say, doing what they ask, waiting on them, waiting for them, serving them, loving them, in short doing anything and everything for them.
In an "attention economy" it becomes possible to benefit from revealing as much as possible about oneself, including weaknesses, and just about anything else. That way, humanizing oneself not only stir up interest, but makes it easier for others to imagine themselves in one's shoes, which means turning their minds to see from one's eyes, a key part of any "paying of attention". Conversely, hiding away will likely turn attention elsewhere and create a risk of losing at least some of one's attention capital.

When they are not in the same place, peoples maintain presence and proximity through communication. Not through images, or appearance, but by maintaining communication. Beyond this, I think that presence technologies influence and enhance our proximity to one another.

Presence occurs when part or all of an individual's experience is mediated not only by the human senses and perceptual processes but also by human-made technology (i.e., "second order" mediated experience) while the person perceives the experience as if it is only mediated by human senses and perceptual processes (i.e., "first order mediated experience).

Early conceptions limited presence to its spatial and physical context, partly because of the technical nature of the mediation. But timing, rhythm, speed, and continuity, despite having a temporal quality that is easily disrupted by technical mediation, are critical to human communication and social interaction. They are more difficult for us to model and render, but nonetheless, I believe that temporal distortions participate fundamentally in one's sense of being on the same page, being in synch, having or sharing time together.
As a consequence, proximity should not only be based on spatial co-presence anymore, but instead tuned to the frequencies of virtual presence. Proximity in the age of its technical production becomes temporal. Proximity mediated through presence technologies produces continuity in spite of physical separation from one another.
In the "social" web, one trades physical presence for virtual presence negotiation in order to get access to people, obtaining their attention, knowing whether a person is there, and there for oneself. Presence technologies provide a temporal continuity through discontinuous participation, creating a sense of being with others who aren't there by projections of oneself in the virtual world. By doing so, presence technologies have the capacity to bring connectedness to people. They help spanning time and weaving a social fabric whose consistency simulate a "being there" for one another in time, but not space.

The real promise of the "social" web is to help satisfy the ever more pressing desire for attention. It's not the associated communication technologies which are important, but rather the individual and social practices into which the technology becomes embedded: messaging, talking, trading, dating, buying, selling, etc… They all participate into how one is perceived as present in the "virtual world". And when everything else has become boring, only "social" presence remains. In this world, I see presence as a social involvement, one that calls out attention, or to put it another way, in the "social" web it is presence that drives the way people trade attention.

In spite of this simple economical equation, none of the so called "social" networks have yet embarked on a re-architecture based on real-time presence technologies; instead they keep using overhauled legacy web techniques.

Technorati Tags: Presence, Social network, Antecipate

Of compartments and silos...

2006-11-13T18:17:00.000+01:00

Brad Casemore presented earlier the upcoming integration of Yahoo! messenger into their mail service interface as

In another example of how online applications are becoming richer and more useful, Yahoo announced today that it will embed instant messaging into its web-based email program within the next few months, allowing users to partake in live chats from Yahoo Mail and to obviate the need for installation of a desktop IM application.

I generally appreciate Brad's comments in the way they keep a positive tone. In this particular case, I am less incline than he is to only find positive aspects in this upcoming integration. First of all, there is this persistence by one of the remaining consumer instant messaging incumbents to stick to proprietary protocols, rather than embracing open and documented standards. But more generally, as I pointed out earlier, I don't think Yahoo's current "me too" attitude is in any way giving a sign of "online application becoming richer and useful". If industry trend there is, it exemplify this industry inability in general, and of Yahoo! in this particular case, to properly grasp the current usage trends, and to provide relevant solutions to problems at hand.

Mike Gotta has perfectly analyzed the growing disaffection for email observed in "the current set of digital natives (those that have grown up using computers)". With the commoditization of tightly interwoven communication tools, the challenge of technology is not to offer a single command point trying to aggregate a "pot-pourri" of legacy and current communication channels, but rather to enable the proper use of the most appropriate channel and to move seamlessly between channels/devices at any time, while keeping the conversation active and rich.

I believe this is the kind of evolution we notice when we observe how teenagers prefer their IM client to an email client. But I would not qualify this of "generational". In my opinion, it results simply from a different "learning" context and different "social" priorities. The important point is that IM is nothing but another channel for communication, although more in line with the natural real-time nature of face-to-face communication than email in the current impersonation of online "social" spaces.
Looking at the upcoming UI mock-up, which does not provide the slightest hint of presence enabled contact list, makes me wonder if anyone at Yahoo! has even noticed that this evolution has already started. From the look of it and the justifications provided in the original announcement , email and IM are still living in far away silos at Yahoo! But can we really expect a walled garden proponent not to keep the few neurons at its disposal in separate cubicles?

As I hinted before, a true improvement would be to provide a generalized messaging interface, and leave the final routing decision to a combination of presence and user action. On the surface, one could argue that the proposed possibility of copying an email under redaction into an IM provides the same functionality. But this would be missing the true nature of asynchronous communication: it is a special case of synchronous communication, not the other way round. And to notice this subtle difference requires thinking out of the silos.

Technorati Tags: Conversation space, Presence, Instant messaging, Usability, Antecipate

Non verbal presence

2006-11-13T12:45:00.000+01:00

I have reported earlier how different media type can affect the nature of peoples' interaction and by consequence influence the medium chosen by an individual who wishes to communicate. Many factors are affecting the level to which a medium is perceived as sociable, warm, sensitive, personal or intimate when it is used to interact with other people. Peoples in distributed environments are adjusting to perceived physical contact and closeness, even if it is not possible, just as people strive for intimacy equilibrium in the real world. They are also eager to retain the possibility of doing interactive acts in this environment, even if they would not do them due to social rules in the real world or the mediated context.
They will thus look for technical mediations involving impressions as much as they involve expression. For technologies that mediate presence, this mean:

Assisting the medium in its production of perception.
Minimizing the distortion or amplification of affective movements.
Allowing the user's action structuring.

I have previously presented views on how some form of feedback, when added to presence technologies, was desirable to minimize the intrusive nature of notifications and, by consequence, to limit some of the medium induced distortion. But I believe presence systems have a natural bias towards machine to machine communication, and most UI (user interface) still fall short at conveying non-verbal contextual cues. Although we find a host of presence attributes that can be aggregated and used to infer "enhanced" availability states, the available rendering techniques to assist the medium and enrich the user's perception of its environment still fall short of providing an adequate answer.

For example, in text based communication systems, commonly used UI substitutes for non-linguistic cues, such as gestures and facial expressions, are avatars, smileys and other fixed design elements. Clearly these "signs" have at best a reduced correlation to the user's intended meanings. And where a user's facial expressions are directly expressive, these are indirectly expressive. In particular, their appearance doesn't vary from user to user. Further more, they have to be interpreted in context. When a smiley used in an UI, the user has to resort not only to its knowledge of the author, but also to the context of email, IM, chat, or whatever communication tool is in use. In that respect, I don't agree with the argument that these design features enhance presence. They just slightly increase the palette of expressions, and minimally assist the medium in producing an impression.

I believe current human facing presence systems, although they like to qualify themselves of "enhanced" presence providers, still exhibits a very primitive capacity to render information about posture and non-verbal cues as they are perceived by the individual to be present in the medium. Maybe this is further amplified by the strong application (vs activity) oriented nature of today’s windowing UIs, and the difficulty many designers have to free themselves from "best practices" when these are nothing but entrenched habits. I think our UIs are showing their age and definitively lack the dynamic and ingredients necessary to the required production of perception.

Technorati Tags: Presence, Conversation space, Antecipate

VoIP is a series of tubes...

2006-11-11T22:59:00.000+01:00

But unlike the Internet, these tubes can be filled without allowing inter-tube communication. Unless I am mistaking, we are getting yet another replay of the "my little walled garden" show, this time with point to point voice communication as the guest star. Just take the same incumbents as in the case of consumer instant messaging services, add eBay with Skype, and Google with GTalk and you have the new landscape. What is also interesting is the parallel uptake of VoIP hard phone devices for use with these closed services. We already knew the series of Skype phones, but more recently the movement has accelerated with examples of Yahoo! and GTalk phones.

I will resist enumerating the reasons why walled gardens and non interconnected “tubes” cannot provide a sustainable model, as I have done so here before. But this multiplication of closed voice services and associated devices raise two questions.

Firstly, the technological context in which these services are being created is different from the context of instant messaging. At the time where IM services have originally been created, there was no established standard for instant messaging, which in turn led to the development of proprietary and incompatible protocols. In comparison, SIP was available as an open VoIP standard. So why wasn’t SIP chosen by all these players to incorporate in their soft clients? Apart from AOL which included a SIP stack in its latest AIM clients, the other incumbents, including Microsoft, as well as Skype and Google came up with their own VoIP solution. I have various reasons coming to my mind that could explain why SIP was not chosen, amongst them I can cite:

Inability of the players to conceive voice services outside the existing traditional telco model, where the only conceivable option for them is to play the role of clearing house. Using a proprietary VoIP system would force the end users to go through the incumbent's gateways to reach out to other VoIP services.
Fear that adopting SIP would give an unfair advantage to Microsoft which had clearly endorsed this standard in its enterprise products. The current situation is proving that this possibility was grossly exaggerated, as MSN does not use SIP for VoIP, and there is no concrete proof that SIP is used to a large extend by MSN yet.
Inherent complexity of a SIP solution ranging from the phone configuration, recurring subject cited by many VoIP observers, to the associated infrastructure necessary to support and control the service. Furthermore, SIP is a documented standard, but its standardization process is similar to a vendors' consortium initiative. As a result, most of the SIP equipments are only manufactured by traditional telecom vendors, and the cost of a SIP infrastructure may have been excessive.
Scarce SIP expertise amongst the developers that have been put in charge of implementing the service and integrate voice in the IM clients. Skype and GTalk are typical examples, where developers had a protocol at hand that was solving many issues SIP is facing with NAT traversal. In such condition, it was easiest to just add signaling and voice transport to the existing protocol than to learn SIP in order to embed a full stack.

Secondly, why do all the VoIP pundits remain silent before the obvious rise of these new walls? I find this silence deafening and profoundly puzzling. I don't know if you are like me, but I don't think it is difficult to infer that all these voice services are of no real value to the end user. I was under the impression we were in an era of users' empowerment and "social" communications. Furthermoe, if the attention economy is effectively the natural economy of the Internet, then voice is the first natural way to draw someone else's attention. After all, what does a baby do immediately after it is born but cry to draw attention? Voice is the ultimate open medium, and is the first and most ubiquitous human way of communication, far before writing. But when someone can only use words in the limited context of a closed community, without the possibility to be heard outside, it looks strangely similar to being deprived from basic freedom of speech.

I can hazard a possible explanation to their silence. Maybe the said pundits, having been exposed to long to the traditional telco business, are only able to conceive a single type of voice applications: toll gates, which are the natural complement of non interconnected “tubes”.

Technorati Tags: Interoperability, Conversation space, VoIP, Antecipate

Streamlining remote notifications

2006-11-09T20:03:00.000+01:00

Mridul recent post highlights a point where XMPP could improve its presence notification model when presence subscribers are distributed amongst many servers. That said, the described behavior is by no mean specific to XMPP and is also found in SIP/SIMPLE early specification. As the issue exhibit some commonalities in both protocols, it is not extraordinary that the proposed solutions to decrease the network traffic generated by notifications revolve around notifying lists of subscribers instead of notifying each subscriber in turn. This is a rather common design in many publish/subscribe, where subscriptions' lists are advertised to the brokers nearest to the subscribers, with a task for them to perform the final notification. When applied in the context of XMPP, the driving idea is to delegate the atomic notification to the home presence server for the concerned domain.

Obviously the expected gain only results from a steamlined traffic between servers. The most noticeable gains would only be achieved when a particular user has more than one contact located on a remote server. In an adverse case presenting a widely spread distribution of remote subscribers (i.e. many remote subscribers each on different home servers), the gain would certainly be lower than expected.

The very nature of XMPP, with its persistent presence subscriptions, implies that the two cases in which a large number of presence packets will be exchanged are at the begining and end of a user’s session:

When the initial presence is published after a user login,
When the final presence is published at log out.

At a user login, an XMPP client delegates the appropriate presence notifications to the user’s home server; an initial presence will combine two separate processes:

A notification of the user's presence to all the watchers of its presence state,
A probe of each user's subscriptions to receive the contacts' presence states.

At logout time, only the notification of the final “unavailable” presence to all watchers is taking place.

I disagree with the way the problem is presented in the post, as the described use case assumes that the presence subscriptions between users on each server are symmetrical. Although that may account for a majority of cases, this cannot be extended as a generic case.

I also disagree with the underlying assumption that the two processes of notifying all watchers and probing to receive contacts' presence states are symmetrical. XMPP specifically differentiate between "presence-out" (outgoing notifications) and presence-in (incoming notifications). In effect, probes only occur once at the beginning of a user's session, whereas notifications will happen for every user's presence state change. As a result, I think these two processes have to be handled differently. I also believe support for these two processes would be best discovered and implememented independently by servers. Consequently:

Probing multiple contacts' presence states is a one time operation and can leverage XEP-0033 Extended Stanza Addressing to group all target JIDs in a single stanza. The probe result can be returned by the contacts home server using the same mechanism.
Notifying watchers requires establishing a transient dynamic watchers list on the contacts' home server. This list's address would then be used when sending notifications in order to minimize the inter-server traffic. The contacts' home sever will then be responsible for the local notification of every contact's resouces.

In this later process, I believe that XEP-0144: Roster Item Exchange would be more appropriate that XEP-0033 for the watcher list management. After all, the watcher list we are trying to build is nothing but a roster extract for the subscribers of a particular domain. The XEP-0144 extension provides all necessary management features to add/delete entries in the list. In our particular use case, I think the proper container is best provided by an InfoQuery stanza. An illustration of this approach is given bellow, which assumes the multi-notification service has previously been discovered through XEP-0030:

<iq to="notifier.denmark.lit"  from="horatio@denmark.net" 
       type="set" id="1234">
  <x xmlns='http://jabber.org/protocol/rosterx'> 
    <item action="add" jid="rosencrantz@denmark.lit"/>   
    <item action="add" jid="guildenstern@denmark.lit"/>          
  </x>
</iq>
 
<iq to="horatio@denmark.net" from="notifier.denmark.lit/a341ff7cd2"
       type= "result" id="1234"/>
…
<presence to="notifier.denmark.lit/a341ff7cd2" from="horatio@denmark.net/palace"/>

You will note how the notification service returns the list address in the InfoQuery result, and how this qualified address is used for sending the presence stanza. If the list needs to be later updated during the user's session, it can be achieved incrementally:

<iq to="notifier.denmark.lit/a341ff7cd2"  from="horatio@denmark.net" 
       type="set" id="3456">
  <x xmlns='http://jabber.org/protocol/rosterx'> 
    <item action="add" jid="hamlet@denmark.lit"/>   
  </x>
</iq> 
 
<iq to="horatio@denmark.net" from="notifier.denmark.lit/a341ff7cd2"
       type= "result" id="3456"/>

In order to keep the management of the list simple, I would make the list transient for the duration of a user's session only. The overhead of re-creating it for every user's login is largely offset by a management that do not have to deal with permanent remote lists. The watcher list can be removed either when the final presence "unavailable" is sent to the multi-notification service, or by using a specific InfoQuery request extended with XEP-0144.

The possible side effects related to glitches in communication between the servers will have to be addressed separately using the mechanisms that are currently under discussion at the JSF.

Technorati Tags: XMPP, Jabber, Presence, Antecipate

Media relay hidden query

2006-11-08T20:02:00.000+01:00

I received additional information following my last experiment on Google using media relay. It happens that the GTalk service also implements a full XMPP extension to provide information about its relay servers. This extension, which replaces the "google:relay" query is hidden behind the STUN extension which is documented on their developers' site.

Using my favorite client I was able to check that using the described query gives the result that can be seen bellow:

<iq type="get" to="romeo@gmail.com" id="1" ><query xmlns='google:jingleinfo'/></iq>
<iq from="romeo@gmail.com" type="result" to="romeo@gmail.com/psiC3BE970F" id="1" >
  <query xmlns="google:jingleinfo">
    <stun>
      <server host="stun.l.google.com" udp="19302" />
      <server host="stun1.l.google.com" udp="19302" />
      <server host="stun4.l.google.com" udp="19302" />
      <server host="stun3.l.google.com" udp="19302" />
      <server host="stun2.l.google.com" udp="19302" />
    </stun>
    <relay>
      <token>CAESHgoVamxzZWd1aW5lYXVAZ21haWwuY29tEOCJq4TsIRoQRWsKcIug9O8RySUrR05+tw==</token>
      <server host="relay.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
      <server host="relay2.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
      <server host="relay3.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
      <server host="relay1.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
      <server host="relay4.l.google.com" udp="19295" tcp="19294" tcpssl="443" />
    </relay>
  </query>
</iq>

To conclude, it seems that current GTalk clients (1.0.0.100) are using the HTTP/XMPP combination I described earlier, and that future versions may use this XMPP only query to discover the relay servers. In the meantime, I suppose they are waiting for the extension to be final to add it to the existing documentation…

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, NAT, GoogleTalk, Antecipate

Morphing conversation UI

2006-11-08T19:13:00.000+01:00

I am not a typical "example" when it comes to user interface, and I have my own idiosyncratic preferences, especially for communication applications. In particular, I despise the way we have been forced by the incumbent desktop software players to use mail clients to manage information. Their influence is so insidious, that even their strongest open-source contenders stick to the same screen real estate concept.

I came across this short post by Mike Gotta elaborating on the ineluctable death of the email client as we know it.

Concerning enterprise environments, at some point a few years down the road, shifting demographics as Danah Boyd points out in this post, will have an interesting impact on the future of e-mail clients. Once "digital natives" become a large part of the workforce, it's likely that we'll see a tipping point where users will prefer real-time communication front-ends to async front-ends. Yes, e-mail clients will support unified messaging and will morph to provide a real-time communication (RTC) user experience but younger workers may prefer to live in more natively-designed RTC clients (such as Microsoft Office Communicator and IBM Sametime), especially as those clients support both social and work-related capabilities.

I am a bit disappointed because my relief is not readily in sight, but this analysis is pre-announcing what I believe to be the irreversible evolution of our way to interact with desktop communicating applications. There was a not so distant time where the latest hipe was about getting IP to every workstation. The natural evolution would be to get conversations to the workstations, any type of conversation, and have all the associated communication stacks available as local servers to any application whishing to use them. At that point, it will become obvious that email is just an asynchronous channel for real time text exchange in a wide presence enabled communication system, instead of instant messaging being a real time version of email, as the current generation of "office" software would like us to believe. And I hope this difference will bring UIs more to my taste.

Technorati Tags: Conversation space, Presence, Instant messaging, Usability, Antecipate

VoIP is irrelevant

2006-11-07T17:07:00.000+01:00

At least for the purpose and in the context of this poll! When your [truck, ship, plane, add your own transport here] is stuck in the middle of a distant nowhere following a breakdown, the first thing you think of is getting in touch with the [driver, captain, pilot, etc…]. At that point, your only intention is to communicate, to exchange and gather information, for finally come to some decisions and trigger some actions. And during that process, the last thing you will be worrying about is if part of your communication is carried out using VoIP. It is irrelevant. Even the cost of the communication will become irrelevant. What you would want though, once the communication has been established, is to take photos or videos of the incident to be able to share them with the appropriate expert for deciding on the better course of action, and at the same time to start the claim procedure with your insurance company. What you would want is to quickly gain access to the nearest repair facilities and arrange for you transport to be taken care of, because your business depends of it.

Even if the transport of multiple data streams using the same underlying technology has become increasingly more common, it does not make VoIP relevant in itself. The induced fall of the wall between the voice and data silos is relevant. The ensuing cross domain knowledge dissemination between these two areas of expertise is relevant. The growing awareness of the possibilities offered by merging multiple communication types into applications is relevant. And only at that point will it become relevant to use VoIP, not the other way round. Obviously, all these positive consequences will only happen at the slow pace of human behavior changes. And this is much too slow for the buzz makers.

More profoundly what is relevant is "to impart, to share, to make common". And in that respect, the current impersonations of VoIP are far from providing this basic communication attribute, as they are repeating the creation of wall gardens in the same way early email providers did, in the same way consumer IM providers still do. And by taking this approach, their proponents are as good as the poll's author and other VoIP's meme builders: clueless…

Technorati Tags: VoIP, Antecipate

Relay or no relay, that was the question

2006-11-06T15:56:00.000+01:00

The miracle of the blogosphere happened again. My little rant about Jingle media relaying produced the expected effect, and I now have the answer: Google is effectively using media relaying in GTalk to cater for the 8% of NAT traversal cases not covered by their implementation of ICE. According to the information source,

the client discovers the relay's host, port and other information using a proprietary XMPP extension. The client communicates with the relay service to allocate ports.
It's a proprietary protocol. The team would like to replace the proprietary protocol with TURN.

Earlier today I conducted a simple experience of placing a call between two GTalk clients, with diagnostic logging enabled. Then I looked for an indication of media relaying in the resulting log, and here are my findings.

Immediately after initializing the XMPP session, the client goes on sending the following stanzas before any IM application requests :

[007:201] [8a8] SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Mon Nov 06 10:48:29 2006
[007:201] [8a8]    <presence type="unavailable"/>
[007:201] [8a8] SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Mon Nov 06 10:48:29 2006
[007:211] [8a8]    <iq type="get" id="7">
[007:211] [8a8]      <query xmlns="google:relay"/>
[007:211] [8a8]    </iq>

The client eventually gets an answer from the server:

[007:581] [8a8] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Mon Nov 06 10:48:30 2006
[007:581] [8a8]    <iq to="romeo@gmail.com/Talk.v98734E454A" id="7" type="result">
[007:581] [8a8]      <query xmlns="google:relay">
[007:581] [8a8]        <token>
[007:581] [8a8]          CAESHgoVamxzZWd1aW5lYXVAZ21haWwuY29tEIO2uPPrIRoQEWhSGqW0sC45unw91a8uNg==
[007:581] [8a8]        </token>
[007:581] [8a8]      </query>
[007:581] [8a8]    </iq>

Later on during the exchange, it appears that the client is attempting a connection through HTTP to a relay.l.google.com host:

[138:820] [8a8] HTTPPortAllocator: starting request 1
[138:820] [8a8] HTTPPortAllocator: sending to host relay.l.google.com
[138:840] [8a8] HtmlWindow::GetHostInfo
…
[138:910] [38c] ReuseSocketPool - Creating new socket
[138:910] [38c] Resolving addr in PhysicalSocket::Connect
[138:910] [38c] === DNS RESOLUTION (relay.l.google.com) ===
…
[139:080] [38c] relay.l.google.com resolved to 216.239.37.126
[139:090] [38c] ReuseSocketPool - Opening connection to: relay.l.google.com:80
[139:391] [8a8] HTTPPortAllocator: HTTP request 1 succeeded with code 200

At this stage we enter the Google's Jingle transports candidates' negotiation. The client prepares the various candidates and then goes on trying them in sequence:

[139:401] [c8c] Jingle:Net[0:192.168.254.100]: Allocation Phase=Udp (Step=0)
[139:401] [c8c] Jingle:Port[rtp:local:Net[0:192.168.254.100]]: Added port to allocator
[139:401] [c8c] Jingle:Port[rtp:stun:Net[0:192.168.254.100]]: Added port to allocator
[139:401] [8a8] SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Mon Nov 06 10:50:41 2006
[139:401] [8a8]    <iq to="juliet@gmail.com/Talk.v100C3349241" type="set" id="37">
[139:401] [8a8]      <session xmlns="http://www.google.com/session" type="transport-info" 
                                          id="3854034496" 
                                          initiator="romeo@gmail.com/Talk.v98734E454A">
[139:401] [8a8]        <transport xmlns="http://www.google.com/transport/p2p">
[139:401] [8a8]          <candidate name="rtp" address="192.168.254.100" 
                                                 port="1780" preference="1" 
                                                 username="GYPRLTG33vQGFOTZ" 
                                                 protocol="udp" generation="0" 
                                                 password="47CqsrM5wDUyYbiK" 
                                                 type="local" network="0"/>
[139:401] [8a8]        </transport>
[139:401] [8a8]      </session>
[139:401] [8a8]    </iq>

Following the specification the client determine the best connection from the candidates:

[140:462] [c8c] Jingle:Channel[rtp|__]: New best connection: Conn[0:rtp:local:192.168.254.100:1780->rtp:local:192.168.254.101:1237|C-w]
[140:462] [8a8] SEND >>>>>>>>>>>>>>>>>>>>>>>>> : Mon Nov 06 10:50:42 2006
[140:462] [8a8]    <iq to="juliet@gmail.com/Talk.v100C3349241" id="83" type="result"/>

At this point, the client has established a preferred connection for direct RTP, but it nevertheless goes on and prepare a further connection through the relay, but as my call was local, it did not issued the corresponding candidate, instead connecting point-to-point through the local UDP candidate:

[141:464] [c8c] Jingle:Net[0:192.168.254.100]: Allocation Phase=Relay (Step=1)
[141:464] [c8c] Jingle:Port[rtp:relay:Net[0:192.168.254.100]]: Added port to allocator
[141:464] [c8c] Connecting to relay via udp @ 216.239.37.126:19295
…
[142:525] [c8c] Jingle:Net[0:192.168.254.100]: Allocation Phase=Tcp (Step=2)
[142:525] [c8c] Jingle:Port[rtp:local:Net[0:192.168.254.100]]: Added port to allocator
[142:535] [c8c] Jingle:Conn[0:rtp:local:192.168.254.100:1783->rtp:local:192.168.254.101:1240|--w]: set_connected

From this scenario, I can hazard a hypothesis about the way a GTalk client negotiates media relaying.

The client uses a proprietary XMPP extension to query the relay service and receives an opaque token if the request is successful. I believe the token is destined to authorize a later use of the media relay to the client who made the request.
The client then retrieves the appropriate relay parameters though HTTP, probably presenting the previous token as an authorization reference, and not through an XMPP interface as my source stated.
The client then creates a transport candidate from the received parameters, and assign it a lower priority than the UDP and TCP candidates. It uses this candidate in the transport negotiation sequence.

Although I am missing the proper test environment to verify my hypothesis, my first finding concens the inaccuracies in the description of an otherwise rather standard and expected technical solution. I leave you to decide why the mechanism has been described as XMPP, where in fact it appears to be a mix of HTTP and XMPP. I personally find this disturbing, as it can be leading to more inaccuracies of the sort finding their way into the Jingle specification. I am ready to accept that Google is concerned, but I do not believe disclosing this mechanism will ever put that company at risk.

But, when I reflect on the position taken publicly by the authors of the XMPP Jingle specification in favor of using TURN to deal with media relaying negotiation, I am worried of the possible impact of their stand on the specification completion time and on the ensuing implementation by developers.

As I stated earlier, ICE and TURN are "work in progress" drafts, which have already been lingering at the IETF for over a year since Google announced the GTalk service. During that past year, the activity around the XMPP Jingle specification has been very slow to take up.

On one hand, the specification has only recently been published toward a last call before JSF council approval.
On the other hand, I believe the inherent complexity of media support libraries slows down the implementation of Jingle at the client level because developers need to master these new and unfamiliar concepts.

Apart from notable support in open source IPBX, implemented by developers well versed in the intricacies of media communication programming, I only know of the the Jabbin project as a tentative implementation of a free Jingle client...

I believe it would not be realistic to push at all cost a Jingle specification highly dependent on forthcoming RFCs without any foreseeable time of publication of the said standards. The community would benefit more from an interim specification, leveraging instead existing RFCs, such as raw RTP, STUN and media relaying for NAT traversal, to be later updated when the ICE draft is made into an RFC. This approach would have the added advantage of being less complex from a programming stand-point, and would provide a more gradual learning curve for the developers to get accustomed to the subtleties of multi-media communication.

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, NAT, TURN, Antecipate

Media relay: the reTURN

2006-11-05T16:24:00.000+01:00

I am coming back to the subject of using media relay proxies for hard to solve cases of NAT (Network Address Translation) traversals. From the ensuing discussions both on the JSF mailing lists, and through private mails, I have gathered two points which in my opinion illustrate perfectly why protocol definition requires an open mind of every moment. The first opinion was expressed as

I think we can both agree that relay is bad; it adds latency and requires server resources.

and the second as

Since you're already talking to a STUN server for ICE, it makes sense to get your media candidates from the STUN server (i.e., via TURN).

In the first case, the author is using what the list of "Fallacious Arguments" describes as a mix of Argument by Question and Changing the Subject to displace the problem. In his introduction to TURN, Jonathan Rosenberg expresses the fact that a media relay function comes at a cost:

Though a relayed address is highly likely to work when corresponding with a peer, it comes at high cost to the provider of the relay service. As a consequence, relayed transport addresses should only be used as a last resort.

But he does it in context, as someone writing a protocol enabling a media relay function. He does not question the validity of doing media relay, he merely points out that this is expensive, and he goes on explaining how, in his view, the protocol must be architected to allow the feature. We may have different opinions on how to tackle certain issues, but I respect his professional approach at writing protocols: he does not take a subjective view and question the legitimacy of using media relay, instead he propose a solution on how to do it. He does not presuppose a single usage of the technology; instead he admits that a use case may exist. He does not displace the problem to avoid it; he merely tackles it.

In the original discussion that led to the first point, the ICE negotiation used by Google in its version of Jingle was said to be successful in 92% of NAT traversal cases without the assistance of media relaying. Although this is a tremendous achievement, it still leaves out 8% of edge cases where this technique is ineffective. Taken from Google's perspective, this may look sufficient to serve its own users' population. But taken from a protocol perspective, it makes describing how the protocol must be extended to cater for these other cases necessary. And, following the concept of Argument from Authority, I will quote Jonathan Rosenberg again:

… if a client is behind a NAT whose mapping behavior is address or address and port dependent (sometimes called "bad" NATs), the reflexive transport address will not be usable for communicating with a peer.
The only way to obtain a transport address that can be used for corresponding with a peer through such a NAT is to make use of a relay.

I believe that at this point we have established media relaying as an integral part of the arsenal available to the developers to perform NAT traversals. Moving on to the second opinion, it is somewhat reminiscent of Causal Reductionism. Behind the very respectable attitude which consists in not re-inventing the wheel, lies a bias toward a particular solution because the author does not consider in which particular context this solution has been developed.

If we consider the context in which TURN was designed, I can safely pretend that it was strongly influenced by the SIP standardization effort. In essence, TURN was created to address a very real shortcoming is the signaling protocol: it has the same NAT traversal issues as the media streams because SIP allows the use of UDP as its own transport. This consequently implies that media relaying can only be discovered and negotiated on the same transport as the media itself. In comparison, Jingle does not experience the same shortcomings as SIP, as XMPP is vastly superior at dealing with NAT and firewall traversal. As a result, to the contrary of SIP, Jingle can be leveraged to provide the same answer than TURN to the question: what relaying IP:port address should my client use as a last resort?

A careful study of the TURN draft exposes how the shortcoming of the signaling layer (SIP) forces a large part of the signaling to be reincorporated inside the media transport. The solution proposed in the TURN draft also forces the TURN server to authenticate the streams, and by consequence to have access to user's authentication data. Knowing that a TURN server has to be exposed on the public Internet, I can only imagine how corporation will react at this requirement.

On the other hand, an XMPP extension to query and allocate an IP:port address on a media relay present at least two advantages:

It would benefit from the inherent trust established at the user's login time on its home XMPP server.
It would greatly simplify the media relay server, as the implementation of TURN is complex.

To conclude, I believe that the simplest solutions are always better at solving technical issues. In this particular case, the complexity of a TURN solution is not required to provide the expected service. A simple XMPP query can be devised to provide the same result.

Furthermore, I am certain that Google offering a VoIP solution in its GTalk service was the result of a thoughtful business process. But at the same time, Google hands off approach to motivate its developers, has left the implementation been only driven by a technical view point. When specifying the Jingle protocol, a problem arises if the same developers are also co-authors of the Jingle specification: they remain framed within the Google context of consumer oriented service and do not seem to apprehend the wider complexity of the enterprise. But it takes time to be able to recognise the difference between enabling solutions and building frameworks…

Technorati Tags: XMPP, Jabber, Jingle, SIP, VoIP, Session signaling, NAT, TURN, Antecipate

IPBX 2.0 anyone?

2006-11-03T11:02:00.000+01:00

Andy Abramson had a struck of genius last night: he suddenly discovered that IPBX has a future in enterprises.

The future for Asterisk in my mind will be built upon adoption in the enterprise, not by small five to ten end point deployments

For all it is worth, I was under the impression the acronym meant something like "Private Branch Exchange", which does not hold any presumption on the size of what/who is privately using the exchange. As a matter of facts, nothing is precluding enterprises of any size to fall into that category.

Now one may ask why it has not happened yet, and why only "small five to ten end point deployments" are using Asterisk? Because Asterisk’s architecture is nothing but a POTS PBX with IP connectivity. In essence, it is similar to all the big telecom vendor's PBX offerings such as [add you favorite model from Alcatel, Avaya, Nortel, Siemens, etc… here], when they added VoIP support adaptors to make them "IP communication ready". At the core, these systems were still entirely subject to the tyranny of the "numbering plan". A rather rigid dependence, which is far from the flexibility provided by Internet's URIs.

In the end, Andy is right, the future of IPBX is in the enterprise, but any marketer fresh out of school would have said the same. On the other hand, I believe Andy is wrong and, because of its outdated architecture, Asterisk will not be wining this race. In my opinion, FreeSWITCH is a much better candidate to the title of IPBX 2.0 in the enterprise. It is build around the concept of what I would call a ubiquitous "signalling router" which captures the distributed nature of the Internet. Because of its routed architecture, this IPBX can be easily assembled in PBX grids and offer a host of standard IP signalling protocols for interoperability with many real-time communication and presence enabled systems. And obviously it knows how to bridge different media streams…

Technorati Tags: XMPP, Jingle, VoIP, SIP, IPBX, Phone system, Antecipate

At your presence's convenience

2006-11-02T19:04:00.000+01:00

Several researches agree that people are very ineffective at working on too many things at the same time, because of the limited human multitasking capabilities. They conclude that switching from one task to another is particularly costly, especially if the current task has an important cognitive load, as opposed to repetitive tasks based on pattern recognition. When taken in the context of the ever increasing reliance on information, nowadays human attention has become a scarce resource whereas information abounds.

I particularly appreciate the "savor" Alec Saunder's brings to the reflection on interruptions when he writes:

One of the casualties of the last 25 years has been the social compact governing when it is acceptable to interrupt, and when not 125 years ago, before the telephone, if a gentleman wanted to meet another gentleman, he'd send his man around with a calling card to invite the other to meet. It was the presence of its day. It's a metaphor that we really need to examine carefully, because there's much to be learned that is applicable now First, it's completely individual. Whether I choose to meet with Mike, but not Ted, is completely dependent on the circumstances and context the requestor and requested parties find themselves in. Second, the decision making process is completely private. Unlike presence today ("Hey, I can see he's online, but he's not answering my ping! Ignorant b*stard!"), the decision making process was completely opaque to the caller.

He goes on saying that “presence does not model the social contract between individuals”, but rather the cold behavior of communication device. I would furthermore add that "immediacy" has taken down all the polite approach that was allowing the choice of the "time and place" by the parties. By denying this choice, presence notifications in their current forms take a growing part at lowering people's already diminished attention support.

Whilst at the level of the perception (see, hear, feel) people's attention is influenced by external stimuli, goals, motivations, and intentions impact how they focus their attention. Furthermore, these two processes constantly interact to determine one's attention state. In a group, for example, an external stimulus may attract a member's attention, but the lack of motivation for the proposed focus will quickly divert its attention to another item. Alternatively, one may have a strong motivation to focus on a certain item, but an inappropriate presentation of the item content may hinder the desired focus to be established. Perturbations of the delicate balance between perception and motivation often results in an attention deficit, and in turn in lower productivity.

In situations of frequent interruptions or tasks alternance, researchers have noted a significant increase in cognitive load following the actions necessary to restore the context of an interrupted task. Resuming a task is already difficult in the context of current workstation interfaces, as these interfaces use an "application oriented" rather than "task oriented" approach to computer activities. In order to complete a task a user is obliged to fragment the task in subtasks, such as collecting data from a spreadsheet and pasting it in a word processor document. This artificial fragmentation of the original task increases the cognitive load on the user, and interruptions further erode its attention support.
As multi-tasking and interruptions become the norm in working environments, it is important for awareness systems to support the user's attention by supplying personalized and adaptable notification, thus reducing the resulting disruption. Interruption and notification must take into account many factors spanning across the various aspects of attention and contribute to making an interruption more or less appropriate or disruptive. In my opinion, the most important aspects to consider must include:

The context of interruption,
The timing of the interruption,
The content of the interruption.

As I stated earlier, in face to face situations, human beings are able, in a very short time, and with a limited knowledge of other people's activity, of deciding whether an interruption would be acceptable or not. In particular, I believe the exact point in time when the notification is delivered makes a significant difference on whether and how the interruption is perceived and on how much disruption it will bring to the current task.
Recent studies on notification timing have highlighted four types of solutions to manage user interruptions: "immediate, negotiated, mediated, and scheduled". Interruptions can be delivered at the soonest (immediate), or the person has explicit control over when they will handle the interruption (negotiation). A third party system may also dynamically decide when best to interrupt the user (mediated), or always hold all interruptions and deliver them at a predefined time (scheduled). In most situations negotiation is said to be the best choice. But I believe adding feedback to presence will require exploring dynamic combinations of negotiation and mediation.

Technorati Tags: Presence, Antecipate

Ostriches don't solve problems...

2006-11-02T13:15:00.000+01:00

As reminded by Ken Kamp, entrepreneurs and executives sit around board room tables to discuss real business problems and look for real solutions to those problems. That does not include their existing phone systems, services, or expenses. Even less VoIP, SIP or Jingle… Let me illustrate by the following story.

The Capulet family has been running a flourishing wine business, and has succeeded by maintaining a tight focus on its core activities. They are well known for their almost real time customer service and their proximity sales service. Now that they are extending their reach well beyond the comfort of the provincial borders, they have signed up for the latest presence enabled real-time communication system provided by Veronizon. The Capulets have long been running their own XMPP server for fast internal messaging. But they have to make sure all relevant business communications are seamlessly routed to the appropriate representative, without creating undue distraction. And this is precisely what the rule based presence engine of Veronizon's intelligent centrex service allow them to do. Obviously, the service offers all the necessary gateways to ensure that they could also reach their marquee customers or distributors wherever they are, and whatever communication system they use. And guess what, Veronizon charge its service on the number of rules held in the system, and by the number of time these rules are used. The communication time is free, which adds a compelling advantage in regards to the traffic based charges still in use at all other communication providers.

This is in my opinion a very likely scenario for many enterprises wanting to leverage IT and communications for what they are: a support for their business. And in this context what is any protocol's "raison d'etre" if not allowing the brightest entrepreneurs and service providers to propose adapted business problem solving responses to these enterprises.

If we examine the consequences for Jingle in enabling this type of service to be implemented outside the premises of the Capulet's business. We can easily see that the Jingle signaling path must be re-routed through the Veronizon centrex service in order for the relevant call routing decision to be made. Juliet which is working in the family's estate has programmed her personal centrex rule engine to forward immediately any call from Romeo to her. When Romeo select "initiate call" on his favorite client, Jingle will start negotiating a session with Juliet's client.

<iq to='juliet@capulet.com' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

The Montague XMPP server will faithfully route the request over S2S to the Capulet server. Following the contact with Veronizon, the Capulet server has received a new plugin that

Filters all Jingle signaling stanzas,
Reroute the filtered stanzas to the Veronizon centrex service.

thus making the service invisible and transparent to standard Jingle clients.

In order to enable the rerouting, the plugin modify the Jingle stanza by specifying the centrex service address as the new target, and adding a XEP-0033 extended address to retain the original target JID. The Capulet server can thus route the stanza to the centex service over S2S.

<iq to='centrex.veronizon.com' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <addresses xmlns='http://jabber.org/protocol/address'>
       <address type='to' jid='juliet@capulet.com'/>
   </addresses>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

Upon receiving the stanza, the centrex service feeds the incoming request to Juliet's private rule engine, and determines that Juliet is currently available for taking Romeo's call on her "balcony" resource. The centrex service then modifies Juliet's JID to reflect her availability, and forward the stanza to the Capulet server over S2S for final delivery.

<iq to='juliet@capulet.com/balcony' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

In the end, customers don't care about what a protocol, a platform or any technical implementation is doing under the covers. They care about their business problems and solutions to those problems. Protocols and platforms are just the enablers for smart solution providers to deliver on their promises.

The danger for protocols' authors is to only consider the world through the lens of a 17 inches screen, as they may be losing sight of reality. Just bluntly stating that a scenario is unlikely because one never thought of it or never came across it before will in no way make this scenario improbable. How many times have we heard stories about customers using an application or a protocol in a way nobody ever thought before? This is just how progresses are made. Protocol authors and developers often get sidetracked into how to achieve technical interoperability only. I unfortunately believe it is still rather common for them to proclaim that certain usage scenarios do not make any technical sense in the light of their own perception of the problems to solve, and to evade providing solutions by just “hiding their head in the sand”. Until they start to realize this attitude is not enhancing their reputation, they will be considered obstacles more than advantages by many solution providers who build solutions rather than platforms. And, as Ken put it, “those are the ones who will win in the market”…

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, Interoperability, Antecipate

They want to know everything

2006-11-02T01:10:00.000+01:00

It appears that Google, tired of being reminded by its users, has finally implemented an important feature available on any other XMPP instant messaging server for its GTalk service: offline messages. And it has pushed the limit of integration by making these offline messages directly readable in GMail, as well as through any XMPP client.

All is good, all is great, until one reads the last line of the post:

Your Google Talk account needs to have a Gmail inbox with chat history enabled in order to receive offline messages, so make sure to turn it on now!

The offline message storage feature is only active if the chat messages history, which record all your conversations, is enabled in your account. In short, to capture the last message sent to someone who has just disconnected, Google needs to capture your entire chat history in real time. Come on! You are telling me no one in the army of Google's PhD level developers has been able to come up with a simpler solution to capture just these last second messages? I find this rather incredible.

Unless this scheme has been devised on purpose, forcing indirectly those who have made this very useful feature a top request to turn on the chat message history, and allow Google crawlers to search these messages…

Technorati Tags: XMPP, Google Talk, Digital privacy, Antecipate

Multi-homing Jingle

2006-10-31T10:14:00.000+01:00

I described in an earlier post how some edge cases of NAT traversal for media steams could be solved using a media relay proxy. This kind of proxy is widely used amongst well know peer-to-peer VoIP implementations, such as Skype or SIP based devices. SIP based application in most cases use media relay proxies co-located with SIP border controllers (for service providers) or SIP proxies. Skype uses its clients that are not behind NATs to proxy data for clients behind NATs.
While discussing this subject on the JSF mailing lists, an important question have drawn my attention: How would Jingle allow a media relay proxy to be reached when it is not co-located with the client's home server?

The current Jingle specification has been designed with direct peer-to-peer communication in mind, and does not provide built-in support for intermediary relays on either the media path or the signaling path. The Jingle syntax provides a way to redirect a session to a different remote party if the original target is unavailable for the appropriate media communication. This feature is handy when several devices with different capabilities are online for a given user JID, or when the user has set his client to re-route calls to a voice/video mailbox.

However, nothing in Jingle allows for the use of a relay or an intermediary media proxy of any sort. An intermediary proxy has several application use cases. One is the media relay proxy to perform NAT traversal as described in my previous post. But any simple IPBX would equally benefit from this extension. The current flavor of Jingle does not allow referring to an IPBX as a separate server, which is the most common architecture found either at service providers or in the enterprise. Anyone would understand the interest of integrating with IPBX. The "numbering" plan for the IPBX could be defined purely in terms of URIs rather than extension numbers for example. And obviously all the expected exchange functions would be provided by a specialized application, including transparent bridging with other signaling and media protocols.

To that aim the Jingle specification can easily be extended by adding

A discovery mechanism for intermediary media proxies, which will as usual leverage XEP-0030 Service Discovery. It boils down to defining the proper categories and features in the XMPP registrar.
A mechanism in the protocol to allow defining a remote party URI independently from the destination address of the wrapping stanza.

Contrary to a redirection, which is an indication given by the remote party, relaying has to be requested by the initiating party. Once again we can simply leverage existing XMPP extensions and implemented the forwarding by using XEP-0033 Extended Stanza Addressing with Jingle.
In the now traditional context of XMPP examples, assuming Romeo's client has discovered that Juliet is only reachable through a relay media proxy, it would issue a request similar to this:

<iq to='relay.capulet.com' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <addresses xmlns='http://jabber.org/protocol/address'>
       <address type='to' jid=' juliet@capulet.com/balcony '/>
   </addresses>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='this-is-the-audio-content'>
      <description xmlns='http://jabber.org/protocol/jingle/description/audio'>
        ...
      </description>
      <transport xmlns='http://jabber.org/protocol/jingle/transport/ice'>
        ...
      </transport>
      <transport xmlns='http://jabber.org/protocol/jingle/transport/raw-udp'>
        ...
      </transport>
    </content>
        ...
  </jingle>
</iq>

Just including an extended address in the Jingle stanza opens up a host of possible new applications without modifying the actual Jingle negotiation. It exemplify once gain the flexibility of XMPP.

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, Interoperability, NAT, Antecipate

Jingle media relaying

2006-10-29T18:59:00.000+01:00

In an ideal Internet, each device would have a routable IP address all devices would be able to communicate end to end without any intermediaries except routers. In reality, devices connected on the Internet are using a NAT (Network Address Translation) function present in the border router. Using NAT, it becomes possible to connect multiple devices to the Internet by only using one public IP address. On the other hand, it becomes impossible to initiate connections from the Internet. Traversing NAT in both directions becomes an issue when doing point-to-point communications. This is particularly true when using RTP for multimedia communications.

A device behind NAT does not know much about how it will be seen from the Internet, it only knows its own IP address and the ports where the application runs. When communication with the Internet is established, the NAT function maps the IP:port combination of the device on the private NAT interface to a temporary public IP:port combination on the public interface connected to the Internet. Furthermore, the RTP transport protocol usually uses a random port. This means that users cannot just open a port on their NAT device for RTP.

Media consists of one or multiple streams which are negotiated in an associated signaling, such as SIP or Jingle. The signaling protocol allows devices to negotiate a set of common media. The negotiation is performed conveying information about the media streams, such as address where the media will be received, codec types, bandwidth, etc... The problem is that the signaling conveys information about the private IP of the device when it is behind NAT. There are two ways to solve this issue.

One is using a signaling protocol able to negotiate dynamically a communication path for the media even after the initial session has been setup. ICE (Interactive Connection Establishment) is such a protocol, which allows devices to probe for multiple paths of communication by trying different ports and STUN techniques. With ICE support devices have a good chance to handle point-to-point communication without any intermediary media relay. But ICE is awaiting full specification, and therefore only experimental support is provided. In addition, depending on the type of NAT, the communication might not be established even when using ICE. In this case a media relay proxy with a public Internet address must be used.

To transparently establish a multimedia session through a media relay proxy, it is best to use a service that associate the media proxy with a signaling proxy. The media relay proxy does the actual RTP traffic forwarding between the parties involved in the conversation. Upon request from the signaling proxy, it allocates sockets for each media stream of a session. The signaling proxy will use the media relay proxy's IP address and socket's port to replace the original values in the signaling payload. For SIP this would be achieved by modifying the SDP payload, for Jingle this would require changing the transport candidate. After this is done, the parties involved in the conversation will contact the media relay proxy thinking they contact the other party.

This approach is needed because the media relay proxy would then be able to determine the addresses from where the media streams originate. This information is unknown when the signaling takes place, and can only be determined when the RTP streams actually start.
After the media relay proxy has allocated the sockets for each stream, it will listen for an incoming packet from each of the two parties. Once these are received, the media relay proxy is able to know where the packets should be forwarded and can start relaying them between the parties. However, if one party has a public Internet address, the media relay proxy is able to send packets to it before it receives a packet from it, since the party's IP:port is already known. Because of this, it becomes possible to chain media relay proxies between them.

It is interesting to note that the media relay proxy solution is independent from the actual signaling protocol. Several solutions already exist for SIP, with the added complexity that SIP itself will require a NAT traversal solution when transported over UDP. I will describe how a media relay proxy can be implemented in XMPP using the Jingle signaling. As explained above, the media relay proxy must be on the public Internet. The easiest approach would in my opinion consist in implementing the media relay proxy as a component of an XMPP server, and install it into a DMZ. Doing so has the advantage of leveraging the trust relationship between the Jingle client and the XMPP server and extending it to the media relay proxy.

The XMPP server would have to be modified to route the incoming Jingle traffic through the component, which will in turn intercept and modify the Jingle transport negotiation payloads:

For raw UDP transport, the component will replace the original transport candidate using the IP:port of a newly created socket.
For an ICE transport, the component will create a new candidate using the IP:port of a newly created socket, and discard any other candidate directly by either parties. As the proxy is always reachable, this connection will always be established.

This example demonstrate that existing multimedia NAT traversal techniques can easily be adapted for Jingle, with the added advantage that the Jingle signaling itself is NAT and firewall friendly, which is not the case of SIP. This use case can also be extended by support both SIP and Jingle on the same media relay proxy component to provide seamless media connectivity between SIP and Jingle clients.

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, Interoperability, NAT, Antecipate

Feedback enabled presence

2006-10-26T20:12:00.000+02:00

Alec Sanders deplores the rather crude state of today's presence systems where only a limited availability awareness is supported. I would add that, in the context of human communications, the mono-directional propagation of presence states without feedback does not help improve an already minimalist replacement for face-to-face communication.

In every day's life, people have an expectation that information about them is ephemeral and subject to the errands of human memory. This ambiguity gives people the ability to influence other's memory and manage the way in which they are perceived. With recording and analyzing of presence information, it becomes more difficult for individuals to adjust how they are “read”. Capture and propagation of presence states complicates one's ability to provide only the information reflecting positively on one's image. A presence system may be disclosing undesired information. Moreover, because distributed presence systems do not allow people to watch how others interpret this information, it decreases one's ability to detect variations in how others accept the image one is attempting to project.

I believe successful presence systems will be those dealing with this kind of “impression management” concerns by providing more control on people's self image projection and interpretation.
These systems will have to carefully balance the recipient's desire for control with the caller's desire to understand the recipient's context, while maintaining trust and usefulness. Today's approach of putting control of accessibility exclusively in the hands of the recipient is not consistent with face-to-face communication. In real life, the caller and the recipient share the context, and can both feel when starting or holding a conversation is not appropriate.

It is interesting to note that experiments conducted recently on awareness systems did not reveal a decrease in the frequency of interruptions. When callers take the recipient's context into account, it has been observed that they adopt a more polite approach to interruption. For example, a caller might say, "I see you're busy, but I have a quick question," or "can you call me when you're free?" At this point, a recipient has an opportunity to provide feedback on how appropriate the interruption is.
Real-time communication systems do not support the many subtle cues people use in face-to-face conversation to convey such feedback. Callers are unaware of the recipient's context and cannot be held accountable for any disruption this may cause. Providing presence information in return will allow some amount of accountability.

Overall, I believe a deeper understanding of how presence supports and breaks social feedback mechanisms would greatly benefit designers and architects.

Technorati Tags: Presence, Antecipate

Real-time utterances

2006-10-26T16:09:00.000+02:00

Interestingly, Janne asks if the web is not slowly but surely discovering the other side: real-time communication. I find the question interesting because it is a confirmation sign of a changing mind set. The web as it has been defined and implemented is about references and location of resources. Obviously, the recent development of feed technologies over HTTP has allowed to venture at the fringe of real-time communication. But this is, in my opinion, more a technology 'long tail' than long term engineering and efficient use of resources.

If the web is to become more than just a clumsy avatar of real life, it must encompass our inherent thinking and communicating capabilities. On the web, communication and references are two complementary sides of the way we express ourselves. It is the presence of different contexts that make information, events or transition in information states meaningful.

As communication and references differ and serve different but equally important purposes they need to be supported by appropriate tool sets. HTTP is the undisputed champion on the reference side. On the real-time communication and presence side, I believe XMPP is gaining enough traction to become the next protocol that counts: open, free (i.e not supported by any commercial consortium) and easy to implement and extend.

Technorati Tags: XMPP, Jabber, Antecipate

Seeing is not believing...

2006-10-25T19:03:00.000+02:00

Announcements in the video-conference space have been flourishing lately. I find them interesting as they attempt to provide answers to the crude rendering of virtual conversation spaces when compared to the rich person-to-person interactions of real life. A large telecom vendor has dubbed its system "Telepresence" and is pretending that

You can think of those technologies as precursors to true telepresence that replicates the experience of "being there".

Well, the advent of large flat screens technologies have certainly made it easier to cover an entire wall with screen panels, but the result remains far from the participants individual holographic representations in the Jedis meetings of "Star Wars"… In my opinion, these video-conference systems fall short in the way they provide view points, usually through a limited number of video cameras. And this latest offering of a well known software vendor claiming to provide

a 360-degree, panoramic video of side-by-side images of everyone who taking part in the conference.

will not make me change my opinion...

Real life shared conversation spaces allow people to maintain instant knowledge about others' interaction with the space. In a virtual world, the concept of conversation space awareness is key for systems wanting to approach the fluid interaction of face-to-face communication.
In physical conversation spaces, participants often shift their attention back and forth between individual and shared activity. In these moments, the space gathers lightweight information such as quick glances at another participant's or its personal area. This information participates in maintaining a sense of awareness of where other persons are and what they are doing. For example, in a work environment, this space awareness would help coordinate tasks and resources. People can use the space awareness to anticipate others' actions, help them with their tasks, and interpret references to objects in context.

Conversation space awareness comes naturally in a face-to-face communication, but it is far more difficult to render in real-time communication systems. In video-conference, only a fraction of the space may be seen, and each participant often does not see the same part as others. More generally, real-time communication systems reduce the richness of communication, and their user interface hides many actions that are visible in a real-life space. Moreover, the perceptual and physical abilities we use to maintain this awareness, such as glances, are replaced with mechanisms that are both slow and clumsy.

As I explained in a previous post, awareness is an essential component of presence. Designers of presence based systems will face two problems to integrate conversation space awareness. First, they will need to know what information should be captured about a person's interaction with the conversation space. Second, they will have to decide how this information should be presented to other participants.

The constituents of conversation space awareness fall into two groups. The first group concerns what is happening to participants:

Amount of activity (How active are the participants?)
Changes in progress (What changes are participants making?)
Expectations (What do participants need me to do next?)
Nature of actions (What are the participants doing?)

The second group deals with where it is happening in the space:

Focus (Where are the participants?)
Influence (Where can participants make changes?)
Objects in use (What objects are participants using?)
View extents (What can participants see?)

Setting explicit status in a presence system provides a first level of awareness. A second level of awareness can be inferred from events observed inside the conversation space, such as the visible or audible signs of interaction with the space or its artifacts, or the participants' activity behavior. But capturing intentionally public utterances, expressions, or gestures that are not explicitly directed at other participants may prove difficult.

In the end, even if a system integrates information from a variety of sensors and other sources, presence indicators still have a long way to go before they reflect true human nature. The “flat” implementations of today's user interfaces plays certainly in disfavor of a realistic rendering. And then there is the user behavior itself that comes into play. Just because my office's door is open and I happen to be looking outside, don't take it for granted you can come in and interrupt me.

Technorati Tags: Presence, Conversation space, Antecipate

The three legs of presence

2006-10-23T01:33:00.000+02:00

Several researches have largely explored the fields of "social presence" and "awareness". However, in my opinion, the emergence of "social networking" and "virtual community" requires adding the concept of “connectedness” to the features mix of any effective real-time communication system. I believe important to review these concepts and see how they inter-relate. These relations will have to be considered carefully when building what is commonly called "presence" into these communication systems.

The concept of "awareness" has been used in many ways. Fifteen yeas ago, academics defined it as

an understanding of the activities of others, which provides a context for your own activity.

Awareness is usually classified into four types:

availability awareness, which relates to the availability of people and objects.
contextual awareness, which includes physical, social and mental context.
group awareness, which promotes the feeling of belonging to a group.
workplace awareness, which is knowledge of tasks within the virtual environment.

In these definitions, awareness is used in the sense of feeling what is believed to be an external perception, whether synchronous or near-asynchronous. It encompasses both a perception of the users of a system, and a feature of a system that facilitates that perception.

The concept of “social presence” is more ancient. Thirty years ago Short et al. in “The Social Psychology of Telecommunications” defined it as:

the degree of perception of the other person in a mediated communication and the consequent perception of their interpersonal interaction.

More recently, in “Criteria and Scope conditions for a Theory and Measure of Social Presence”, Biocca et al. depicted social presence as pertaining to the user, but closely related to the interaction and the medium:

it is a temporary judgment of the nature of interaction with the other, as limited or augmented by the medium.

Social presence theory studies efficiency and satisfaction in the use of different communication media. Short et al consider social presence a subjective dimension of a medium in its capacity to transmit information about facial expression, direction of looking, posture and non-verbal cues as they are perceived to be present in the medium. This dimension affect the level to which a medium is perceived as sociable, warm, sensitive, personal or intimate when it is used to interact with other people. Social presence varies between different media, it affects the nature of the interaction and influence the choice of a medium by an individual wishing to communicate.

The concept of “connectedness” is one of the basic principles which underlie social behavior. In psychology, the fundamental needs for belonging and connectedness are described as powerful drivers to promote social relationships.

Virtual multi-media communication can create a sense of connectedness or “feeling of being in touch”. In awareness systems this may be more important than the content of the communication. Even without direct information exchange, people want to maintain connection with others. Look how instant messaging users monitor the availability of their buddies, and exchange greetings without any need for a real information exchange. Similarly, witness how mobile phone users exchange SMS and share a common, although asynchronous, experience.
There are also situations where connectedness does not imply direct awareness of another person, but rather of an object. Receiving a post card may create a feeling of connectedness although there is no direct awareness of the other person.

Real-time communication systems aim at reducing the spatial constraint in peoples' conversations. Presence has the capacity to convey additional context attributes pertaining to a conversation. If the experience of connectedness is a basic human need, it may help design communication systems enabling connectedness without imitating face-to-face communication, and facilitate "immediacy" and "intimacy" while minimizing intrusiveness.

Technorati Tags: Presence, Antecipate

Walled gardens redux

2006-10-17T16:18:00.000+02:00

In a parallel post I described the landscape in which I consider that walled gardens, such as those still implemented by the incumbent consumer IM, are a flawed strategy.

In short, for any community based service, switching costs remain a critical success factor for building market share and defending against competition. However, as people themselves are increasingly becoming the sources of content and the owners of distribution, we are increasingly seeing an inversion of control, where service providers benefit from customers provided competitive advantages. For a service provider, basing a strategy on directly increasing switching costs by using walled garden becomes antagonist with the users' aspirations. Instead, as the control shifts towards community, a new environment appears where people themselves willingly create their own high switching costs.

When translating to real time communication technologies, it become evident that open protocols offering transparent and unbiquitous communications is the only acceptable way. As a consequence, only widely accepted and implemented open standards will remain. The same shift will apply to communication as it did to content generation and distribution. The end user themselves will want to create their own communication services, and will not accept anything but self imposed constraints. As a result of this new dynamic, they will only choose the easiest to implement and widest ranging protocols. In the end, the most successful services will be those who manage to hide the inherent complexity of any multimedia communication system, while providing unlimited interoperability.

Technorati Tags: Interoperability, Conversation space, Antecipate

Barrier to exit

2006-10-15T13:29:00.000+02:00

A noteworthy "collateral" effect of the Internet is its ability to turn entrenched business positions upside down. As a consequence, thinking strategic approaches to business in a contrarian fashion and experimenting with all sorts of bizarre combinations of services has become the norm for entrepreneurs wanting to grab a piece of the web 2.0 pie. In hope that out of the "mashups" chaos, a few viable models will eventually emerge.

Amongst these experiments, the most in favor are those dealing with "social" [insert your own hype word here] services, where the intended audience is some sort of "community" of interests. The underlying concept is to capture the natural tendency of human beings to gather and talk. Some people will choose to go to "Ye Olde Cheshire Cheese" and do this with a glass of ale; other will login to MySpace… Ultimately though, the most lively and sticky places are those where people communicate whatever the subject, even without subject.

It is important to keep in mind that communications alone does not necessarily act as the primary draw for gathering. Back in the days of consumer online services, email was not effective at acquiring new users. Mainly because most people had no idea what email was and how useful it could be. New users where acquired by showing unique benefits, such as unique content. Yet once they discovered the benefits of email, the mail box became the common ubiquitous reason to join the community. As a result, it is critical to understand that what attracts people initially is often not what keeps people on your network interested in the long run. After all is said, people still hang out in their favorite pub or [insert your own favorite place here] to have conversations.

At the same time, a community generates its own content, and uses its own style in expressing widely its interests. When transferred to the Internet, in a context where people themselves are increasingly becoming the sources of content and the owners of distribution, it becomes clear that any strategy based on increasing switching costs becomes antagonist with the users' aspirations. In effect, we are increasingly seeing an inversion of control, where service providers benefit from customers provided competitive advantages. Switching costs remain a critical success factor for building market share and defending against competition. However, who creates and controls it is fundamentally different from previous services.

Walled gardens are the antithesis of this new dynamic. As the control shifts towards community, a new environment appears where, instead of a service provider locking its customers into a walled garden, people themselves willingly create their own high switching costs. For instance, for an auction service, the switching cost is not the relationship with the service itself, but the reputation and trust a user has spent time building with other community members. For bloggers, the switching cost is not the time spent constructing the blog, but rather the social network of "friends" accumulated over time.

Ultimately, and it may sound like a paradox, the most successful services will offer entire freedom to their user to churn while giving them unlimited communication capabilities. The most successful communities will be those having understood that self imposed constraints at switching are the only ones willingly accepted by members.

Technorati Tags: Interoperability, Conversation space, Antecipate

Jingling the MUC

2006-10-13T14:01:00.000+02:00

I discussed previously how the XEP-0045 specification already contains all the management features to handle Multi User Communication (MUC), beyond simple text chat rooms. At the same time, I was interested to see that discussions are taking place at the Jabber Software Foundation about ways to integrate screen sharing and remote control into XMPP, as well as performing shared XML editing or SVG based white boarding.

MUC provides a very appropriate framework where these different applications can be aggregated. I have already explained how MUC exposes the required components of a generic conversation spaces management. One of the most important characteristics of conversation spaces is the possibility to host public and private conversation in the same space. In essence, conversation spaces simultaneously allow:

point-to-point exchanges between participants,
client-server exchanges, the conversation space being the server.

I believe people have finally come to realize the utopia of considering XMPP as an universal multi-media transport, although there are still bursts of "can I do VoIP over XMPP" here and there… When it comes to multi-media, Jingle is obviously the appropriate answer in the XMPP world.

I nonetheless feel there are still some misunderstandings with Jingle’s concept of separating sessions' establishment operations (signalling) from communication (transport) when a conversation involves more than two parties. In fact this is rather simple. In a Jingle enabled MUC, in addition to the existing XEP-0045 specification the service will only need to implement:

Jingle support for each multi-media conversation spaces in order to answer session requests made to the space JID.
Jingle stanzas' forwarding for session requests made to a space's participant JID.

It is easy to understand that private Jingle session requests made though a MUC are strictly equivalent to session requests between two clients made through a standard XMPP IM server. It is equally easy to understand that the point-to-point media transport between the two participants' clients will take place out of band using the appropriate negotiated binary protocol.

The same scenario applies in a conversation space, when several participants share the same media during the conversation. The difference with the above case lies in the type of end points involved in the point-to-point communication. In order to share a particular media, a mediator system has to combine each individual media flows produced by the various participants into a single media flow. This mixer role is usually played by specialized bridges, or even IPBX, when it comes to voice and video. In the particular case of VNC, I am under the impression this protocol has always been used as a pure point-to-point communications between workstations. As the typical use in the context of a MUC would mostly involve a one-to-many communication (one master screen shown to many participants' clients), adapting VNC screen sharing would require implementing some sort of repeater system.
This same one-to-many communication also applies to streaming media servers that could be used to broadcast inside the conversation space.

In the end, I believe the MUC protocol bears much more than its current limited usage for text chat rooms. I have just tried to illustrate some of the extended possibilities. I am not saying it will be all done in one day, but the proper bricks are already in place.

Technorati Tags: XMPP, Jabber, Jingle, Conversation space, Presence, Antecipate

Multi user communication

2006-10-12T20:09:00.000+02:00

In the XMPP parlance, MUC refers to "Multi User Chat". The specification foreword highlights the textual aspect of the communication by referring to other similar text based systems.

Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services.

In the wake of the growing use of XMPP as an application platform, I am convinced XEP-0045 go far beyond text chat rooms. The specification can easily be extended beyond text to any form of conversation space involving several parties. The word "room" is used throughout the document, and may appear somewhat linked to "chat room". But, leaving this restrictive interpretation aside, we can easily see that almost every concepts used can be applied to the wider scope of conversation spaces.

The first important aspect of the specification is the capacity of its definitions to be applied without changes outside the limitative text communication scope.
The specification provides an exhaustive list of spaces types, such as public (Open, Public) or private (Members-Only, Hidden) spaces, identified (Non-Anonymous) or anonymous (Fully-Anonymous) spaces, temporary (Temporary) or permanent (Persistent) spaces. One can refer to the specification for an exhaustive description of these types. The important point being that these types of spaces are somewhat independent of the actual means of communication used inside the space. They would apply equally well for text, voice or video, or any combination thereof.
Similarly, the specification goes to great length at defining the roles (Moderator, Participant, Visitor) and affiliation (Owner, Admin, Member, Outcast) any participant in a conversation space may acquire, as well as the rules and privileges a compliant implementation must provide in relation to these roles or affiliations. Once again, none of these definitions are specific to text communication. They remain valid for any kind of conversation space.

The second important point is the reliance on presence for the actual conversation spaces functioning. Entering or leaving a space is entirely driven by presence. And the XEP takes great care at defining the associated presence broadcast behavior.
The third important point is the definition of all the management actions that may be associated with a conversation space. For a space owner, it defines a wide range of configuration options. For a space administrator it allows to modify persistent information about user affiliations (e.g., banning) and to grant or revoke moderator privileges. Here again, there is nothing specific to text only communication.

The last important point lies in the possibility to use an XMPP address to refer to any conversation space, and any participant in the space. This fined grained addressing is the key to the extensibility of the "Multi User Chat" to "Multi User Communication". It is easy to imagine that a multi-media conversation space will use Jingle to extend its media capabilities beyond text only. As the conversation space is presence enabled, it will broadcast its capabilities to any client entering the space, while receiving the client's one. Similarly, the space will also broadcast the new participant's client capabilities to all existing participants, thus allowing multi-media private conversations to take place. A Jingle enabled client would then be able to negotiate a voice or video session with a multimedia space seamlessly. It does not matter if the multi-media implementation is entirely provided by the MUC service, or handed over to specialized audio or video bridges.

In the end, the MUC specification is a very important enabler for building advanced communication application, beyond text only. It provides a ready made framework to manage conversation spaces and participants. It is another perfect example of the maturity of the protocol and of the growing importance of presence in application. As I have mentioned earlier, XMPP has reached a stage allowing many application usages from its existing features set. It is just a matter of imagination and creativity…

Technorati Tags: XMPP, Jabber, Jingle, Conversation space, Presence, Antecipate

Moving up the stack

2006-10-11T14:01:00.000+02:00

I have always heard bright people advocating that the real value lies in "applications" and not in the underlying "plumbing". Although some will certainly disagree, there is certainly some truth in the saying…

The recent submission of a new XMPP extension proposal prompted this reflection. The list of XMPP extensions is nearing the 200 and going. The purpose of this proposed addition is quite clear and legitimate:

While a protocol has been described for initiating a file transfer from one user to another, there is not yet a protocol allowing for one user to designate a set of files as available for retrieval by other users of their choosing.

The proposal goes even further by listing the functionalities provided by the protocol extension:

Obtain a list of other client's publicly available files, which match given search criteria. The search protocol is similar to that described in XEP-0055.
Request the transfer of one of those files. The transfer itself would function as described in XEP-0096.
Place requests into a sender-side queue, such that files are sent at a later time.

Unless I am missing something, these functionalities are shared by many resources management applications. Many of these applications always follow the same features' pattern once the service has been discovered:

Traversal of the resource store a.k.a listing,
Finding a particular resource or resource set a.k.a search,
Performing some action on a particular resource.

It happens we already have all the building blocks amongst existing XMPP extensions. In this particular case we would use:

XEP-0030 and XEP-0128 for the files store traversal,
XEP-0055 and XEP-0004 for the files store search,
XEP-0050 for files store manipulation such as file retrieval or removal.

I believe this example shows that XMPP as a protocol has reach the right maturity level, allowing many application usages from its existing features set. There are still unexplored areas were the protocol will need entirely new constructs. This will pobably be the case of very specific application domains, such as the latest discussions around gaming extensions show. In a majority of cases, though, we should see more and more proposals defining existing extensions "mashups" instead.

Technorati Tags: XMPP, Jabber, Antecipate

YOIP (yawns over IP)

2006-10-03T15:21:00.000+02:00

Steering an old stew doesn't turn it into a gourmet meal. And frankly, I think the latest babble-chatter around which VoIP start-up is more voice 2.0 than the other is kind of boring.

I recently left a simple comment on a series of posts describing the "bad practices" dictating the success or failure of new voice and video over IP enterprises: "what should they do to succeed?" Well, the tentative answer has only highten my perplexity. In short, no one seems to knows, but many are talking…

after all is said, more is said than done…

The unease grew even stronger when I red that voice 2.0 in a nutshell sums-up as "be different and give the customer control". What a great discovery! That sounds so marketing 0.1, dear. It just leaves me wondering if anyone is seeing the obvious: until the toll based business model ceases to exist, there are not many chances for large scale innovative and compelling voice applications to emerge. The promise land of converged applications remains a mirage. Unfortunately for all these new enterprises, the issue lies with the networks business model, not with technology. On the positive side though, these VoIP start-ups are helping an ongoing customer education process. Whatever their fate may be, by providing a test bed of other possibilities to end users, they are more valuable than it appears at first sight. Obviously, trying to quantify this value in business terms is open to interpetations. Like any return on peoples’ education…

The troubling feeling I had was further re-enforced when I red the self-congratulating inventor of the so called Voice 2.0 meme suggesting that switching from one's current telecom provider to AOL, Google or [insert your favorite walled garden keeper name here] is the next panacea and will open a wonderful era of user driven voice applications. I doubt refurbishing second hand ideas which have been around since the beginning of the nineties will ever make this meme a reality soon. If like me you have seen so many of these layered voice/directory/application diagrams in any single telecom operator presentation, and so little changes over the same period of time, you remain somewhat skeptical…

As Aesop, this fine observer of humanity, declared, "after all is said, more is said than done". I believe the VoIP meme, in its current voice 2.0 disguise, as well as all its “propagandists” unfortunately do not escape this great saying.

Technorati Tags: VoIP, Interoperability, Antecipate

Let's archive FUD.

2006-10-01T11:39:00.000+02:00

We can draw a parallel between protocols and men: confidence comes with maturity. I believe the latest versions of the public key publishing and message archiving extensions to XMPP are to be interpreted as a concrete sign of maturity. In which way would you ask? In leveraging other existing protocols to their own advantage, in this case the established XML digital signature and encryption.
The process of standardizing a protocol often implies walking a narrow path between the "not invented here" (let's redo everything) and the "narcissistic elitism" (we can do everything) precipices. In my opinion, when protocol's extensions authors rely on somebody else's work, it gives a strong signal they, and by consequence the protocol, have reached an "adult" level of confidence. And in turn, the early natural fears and doubts linked to this kind of endeavor are clearing out.

Going back to the proposed extensions, although I find the public key publishing proposal ready for implementation, I believe the message archiving proposal requires further improvement. Don't get me wrong, I am in no way diminishing the great work provided by the authors. I am just saying that, with few modifications, this archiving proposal could open a much wider perspective in our days of hyper communication.

From the JEP-136 introduction, I read the purpose of the extension.

Many XMPP clients implement some form of client-side message archiving. However, it is not always convenient or even possible to archive messages locally, e.g., because it is easier to keep all archives in one universally accessible place (not scattered around on multiple computers or devices) or because the client operates in a web browser or resides on a mobile device that does not have sufficient local storage for message archiving. In addition, server-side archiving makes it possible to offer new services such as integration of IM and email. Therefore it is beneficial to define methods for server-side archiving of XMPP messages.

In essence, this describes an application process, either manual or automatic, where different conversation threads are recorded to a store for later processing. When you think of it, this is a very natural extension to any communication system. It is also a typical storage application, with typical application subsystems:

Recording rules management (preferences)
Conversations management (collections)
Conversations' items management (messages)
Content replication management

In the end, this is not very different from a mail box or a blog post management application. The transport protocol for interacting with the application will have to be adapted to the appropriate client, but the operations will remain identical: modify, add, delete collections, modify, add, delete items, list store content. And all this is independent of the actual content of the messages or collections. To re-enforce this point, just note how the JEP describes the two cases of clear and encrypted content, and provide adequate methods for both content types. I believe the JEP would greatly benefit using Atom and its extensions instead of an home grown content format.
From a functional stand point, there is no difference between using the JEP proposed content format, and a standardized Atom content, as represented bellow.

<iq type="set" to="montague.net" id="up2">
 <store xmlns="http://jabber.org/protocol/archive"
        with="juliet@capulet.com/chamber"
        start="1469-07-21T02:56:15Z"
        subject="She speaks!">
  <feed xmlns="http://www.w3.org/2005/Atom"
        xmlns:thr="http://purl.org/syndication/thread/1.0">
   <title type="text">She speaks!</title>
   <updated>1469-07-21T02:56:15Z</updated>
   <generator uri="romeo@montague.net" version="1.0">
      Verona client
   </generator>
   <id>60a76c80-d399-11d9-b91C-0003939e0af6</id>
   <entry>
    <id>60a76c80-d399-11d9-b91C-0003939e0af6:0</id>
    <published>1469-07-21T02:56:15Z</published>
    <author>
     <name>Juliet</name>
     <uri>juliet@capulet.com/chamber</uri>
    </author>
    <content type="xmpp" xml:lang="en">
     <body>Art thou not Romeo, and a Montague?</body>
    </content>
   </entry>
   <entry>
    <id>60a76c80-d399-11d9-b91C-0003939e0af6:1</id>
    <published>1469-07-21T02:56:26Z</published>
    <author>
     <name>Romeo</name>
     <uri>romeo@montague.net/orchard</uri>
    </author>
    <thr:in-reply-to ref="60a76c80-d399-11d9-b91C-0003939e0af6:0"/>
    <content type="xmpp" xml:lang="en">
     <body>Neither, fair saint, if either thee dislike.</body>
    </content>
   </entry>
   <entry>
    <id>60a76c80-d399-11d9-b91C-0003939e0af6:2</id>
    <published>1469-07-21T02:56:29Z</published>
    <author>
     <name>Juliet</name>
     <uri>juliet@capulet.com/chamber</uri>
    </author>
    <thr:in-reply-to ref="60a76c80-d399-11d9-b91C-0003939e0af6:1"/>
    <content type="xmpp" xml:lang="en">
     <body>How cam'st thou hither, tell me, and wherefore?</body>
    </content>
   </entry>
   <entry>
    <id>note:60a76c80-d399-11d9-b91C-0003939e0af6:0</id>
    <published>1469-07-21T03:04:35Z</published>
    <author>
     <name>Romeo</name>
     <uri>romeo@montague.net/orchard</uri>
    </author>
    <content type="xhtml" xml:lang="en">
     <div xmlns="http://www.w3.org/1999/xhtml">
       I think she might fancy me.
     </div>
    </content>
   </entry>
  </feed>
 </store>
</iq>

I believe in re-using what has already been thoroughly and critically discussed when it comes to standards covering the same field of application. In this case, with all due respect for the JEP authors, I think most aspects related to expressing web contents are already incorporated in the Atom specification, including standardized extension methods. In comparison, an XMPP specific content format will almost certainly be limitative. I am not certain the JEP authors have had the time to consider all the possible content use cases, which is perfectly understandable. On the other hand, they know XMPP well, and they came up with a good management envelope around the content. I have no doubt they would find adapting the query part of the extension to an Atom content easy.

I know that some of the JEP authors are particularly cautious with the size of what is sent over the network when it comes to wireless clients, and they may object as to the increased size of the XMPP payload. In this precise case, this would not apply, as the JEP is meant initially to provide a service to such limited local storage capacity client. In practice, the kind of content I describe will never be transmitted to these clients.

In the end, the same content information is conveyed, with a much greater content extensibility built into Atom, and the flexibility of XMPP for the transport. And this alone offers a number of possible applications beyond message archiving. For example, the exact same protocol can be used to post to a blog. Using Atom as the exchange format immediately increases the complementarities between XMPP servers and traditional web servers. XMPP servers could expose conversations as feeds. Etc… The end-user imagination only becomes the limit, and not the JEP. And this in turn is invaluable.

Technorati Tags: XMPP, Jabber, Atom, Interoperability, Instant messaging, Antecipate

Come on in!

2006-09-30T12:27:00.000+02:00

It's amazing how small ripples can be made to fill the vacuum by sheer echo relaying. Reading my feed headlines, I came across a mention of Yahoo! opening up its authentication service to third parties. So what? But the post also said that "Dave Winer says this is a huge deal". By reference to the list of "Fallacious Arguments" I used previously, this is typically an Appeal to Authority. Let's check!

As I soon discovered, it was yet another conjectural babbling. After all, what is so extraordinary about another entrenched walled garden community’s keeper offering a service to the rest of the world as long as the rest of the world’s users give custody of some of their identity attributes to the said warden? In the end, these (the wardens) companies make money by selling identity attributes' derived products, such as searching or shopping behaviors or reputations…

To me this is just another expression of the typical lack of imagination unfortunately so common in the current web activity. Instead of trying to solve real end-users issues, such as identity attribute portability, it is certainly easier to invoke an "extended user's choice" and just offer another "me too" service.

As far as I remember, Microsoft started this a few years ago with Passport. And it was deemed so devilish at the time. What has changed since, apart from the number of devils, and the end-users' getting used to it? Microsoft (LiveID), Google (Google Authentication), Amazon (S3) and now Yahoo! (BBAuth) are the most visible examples of the same limited SSO approach. But so are the OpenID, LID, [name your favorite micro ID provider here] and consorts. As a matter of facts, we should perhaps use a different acronym, such as CSO (Centralised Sign On) or [insert your own acronym], instead of SSO. Others said it before, but I do not see how this announcement could be huge in any way except re-enforcing the walled gardens keepers' hold on identity silos. Internet is all about addressing, identity and communication. I believe we are only watching a greater concentration of power in the hands of the same few players. Funnily enough, AOL did not yet made a similar announcement.

I was under the impression the next generation of identity assertion systems had to move away from the concept of "location" based systems, where one is authenticated because he was able to enter a specific "fortress". Instead we're just seeing the multiplication of "fortresses". In this landscape, novel approaches such as what Jason Kolb is trying out look so refreshing…

Technorati Tags: Identity, Digital reputation, Trust, Digital identity, Antecipate

Threading with Atom

2006-09-26T12:34:00.000+02:00

The Atom feed specification has been enriched by a threading extension which further convince me it possess all the required qualities to be used as a standard for instant messaging logs.

As I mentioned earlier, Atom answers more than 90% of what is required to store and communicate content and meta-data for an IM logging system. With the addition of this latest RFC, it would become easier to reconcile IM threads. For example, to support the compliance applications requirements. Or to allow submission to a search engine.

More generally, Atom may become a generalized exchange format for these applications, for any kind of conversation (IM, mail, blogs, wikis, etc…) That may not please the current vendors and their locked in proprietary exchange formats—the famous "we can export data as XML"—but this is what standards are about.

Technorati Tags: XMPP, Jabber, Atom, Interoperability, Instant messaging, Antecipate

Pillars of Hercules

2006-09-25T01:36:00.000+02:00

While researching the commonly expressed concepts regarding naming and addressing, I came across a duet of posts which, in my opinion, exemplify perfectly the noxious effects resulting from entrenched and subjective positions. Having recently discovered this amusing summary list of "fallacious arguments", I though it would be fun to identify if and where the author has been using some of them. In effect, I was able to pinpoint a few interesting usages.

Time and again, we see individuals and organizations inventing new URI schemes in order to tackle the problem of "names" versus "addresses". That is, they want to provide some sort of a globally unique identifier for "This Thing" independent of where representations of that thing might reside. Almost inevitably, these individuals and organizations fall into the trap of thinking that an "http" URI is somehow an address and not a name and is, therefore, inappropriate for their purpose. They are mistaken. I used to believe this too and I was wrong. A new URI scheme is not necessary, nor does it actually solve the problem.

This is a Statement of Conversion. This is defined as a weak form of asserting expertise. The author is implying that he has changed his mind over time, and now that he is better informed, he has rejected a previous opinion.

All along his two posts, the author does nothing but assert that an URL is an URI. Fair enough, but if I am not mistaking this is also what RFC3986 does. But after reading both the RFC and these posts, I am still trying to figure out why would every URI always have to be represented as an HTTP URLs?

URIs are names. They're all names. There's no technical reason to invent new URI schemes to address the goal of providing names that can be created in a distributed fashion, that unambiguously identify a resource, are persistent, and can be used to retrieve representations.

I am not certain if this quote falls under Argument from Adverse Consequences or under Causal Reductionism. The later seems perhaps more appropriate, as in effect the author reduces the array of reasons that could potentially lead to choosing an URI outside the HTTP scheme to the "technical reason"

I agree with the author, there is not technical reason to create new schemes, only real world cases and requirements. I would feel awkward using "there is no technical reasons" to justify a limitation of the possibilities offered to an end-user in the context of his core business, wont you?.

There may be circumstances under which there are compelling reasons not to use http URIs, but no such circumstances have yet been convincingly articulated to me.

This one quote falls clearly under the Argument from Authority. In this area of expertise, the author is actually claiming to be more expert than anyone else in his readership. Now, I leave it to you to decide if there is also an implied claim that expertise in the area is worth having. As to me, I recon a good knowledge is certainly worth having.

Arguments against http URIs based on the cost or inconvenience of maintaining web infrastructure to support access to those URIs don't hold water. I accept that there are some issues of user expectation here, but I don't find those issues sufficient to warrant the invention or use of "pure identifiers"

Once again, we have Argument from Authority, probably combined with a touch of Reductive Fallacy in under valuating the impact of "user expectations".

What is the use of any technology that does not correspond to user expectations? Who can pretend he can grasp every possible concept and use case? For me, pretending that the current state of the internet and the associated infrastructure services are cast in bronze is nothing but utopia. It would deny us any possibility of invention. As one of the comments states, DNS is an important part of the infrastructure which relies on "economy". And as a consequence, the usage of domain names in URLs is driven by a market. To my modest knowledge, there is nothing more variable and subject to change than a market. I would not bet on market driven domain names for persistence or disambiguation.

In the end, there are certainly many cases where an HTTP URL is all what is necessary to name a resource. Web pages are there to assert this. But reducing the naming of all the internet objects to using HTTP URLs is in my opinion both partisan and short sighted. In many real life languages we find common names and family names. They serve different purposes and are used in different contexts. For example, refering to someone as “John Doe the 3rd” does not imply you can derive its location from its name. Why would the case be different for URIs? They do not exist per se, but only to help us solve real world issues. I would have appreciated an approach exposing with slightly more impartiality the different purposes where URIs can be used, such as unique name for a singular thing, address or location, and unique name for a conceptual thing to be used unambiguously.

In the ancient times, the popular belief and the stubbornness of the experts of the time made the Pillars of Hercules the western end of the Earth where the sun sets. Later we found there was a new world beyond them. Why would our internet age be so different… In the meantime I am still researching.

Technorati Tags: Addressing, Antecipate

Evolution in a fuzzy future

2006-09-24T21:34:00.000+02:00

Mickaël Rémond kindly point out he does not perceive Flash as the magical cure to the multiplatform incompatibilities plaguing many web applications. I agree entirely. It is just a step toward decreasing the collateral effects of having to support several web browser variations. As matter of fact, my remark about unsupported browsers was more destined to highlight the lack of respect many recent web sites exhibit in dismissing the ability of an end-user to use its browser of choice.

That said, why Mickaël only choose 51 words out of the 1165 comprising my post still puzzles me… Is this argument by selective reading? I would rather believe the phrase he quoted triggered the need to express in his own words an unfortunate reality.

He makes the point that ActionScript3 requires an upgrade of the flash player. I do not see anything really new with this approach. From what I understand ActionScript3 requires a more recent version of the associated virtual machine to run. What is so special about it? Other runtime environments evolve similarly. It is true of Java, Flash, PHP, [add you own favorite interpreted language here] and many others. The benefit of added features rarely occurs without an upgrade, otherwise all softwares would already have been carved in stone… As an end-user, what matters first hand is the backward compatibility, so my existing applications do not require rewriting. This way I can decide solely in view of my business requirements that the added features or performance improvements may boost my business and decide to use the upgrade without being forced into it.

On the unfirtunate lack of adequate Flash player releases for the Linux operating system, I can only deduce from what Mickaël has been writing that this particular population unfortunately do not fall within the "target" decided by the persons in charge of the Flash player business development. Frankly, beyond noting the fact and agreeing it looks certainly unfair, I doubt we can do much about it.

For sure the future is fuzzy, but not only in relation to web frameworks. I don't believe I will live long enough to see a single ubiquitous operating system running on many different machine architectures, nor by consequence any universal tool set spanning all contexts and needs. And in all fairness it would be such a bore… But any evolutionary step decreasing the artificially created disparities between platforms is welcome. In this context, I re-iterate that XIFF and Flash together make A very strong contender for building rich client XMPP enabled application. I am not implying this is the only one. I just believe it is an encouraging sign which opens up better possibilities for a population of developers that did not benefit of an adequate toolkit choice previously.

Technorati Tags: XMPP, Jabber, Flash, Antecipate

Flash fat belly

2006-09-23T18:14:00.000+02:00

One of the interesting enhancements to the XMPP toolkits portfolio is the porting of the XIFF Flash library to ActionScript3. There is say in the software industry that a product only reaches full readiness at its third release. ActionScript seems to fit perfectly into that category. Its latest version has enabled Nick Velloff and Derrick Grigg to take advantage of the language better structure and network support to build a very promising XMPP library. As a bonus, with the native socket support now part of ActionScript, the null terminating character so specific of the previous Flash clients is now gone.
XIFF and Flash together make a very strong contender for building rich client XMPP enabled application without suffering this dreaded message one see on so many web 2.0 mashups "your browser is not supported, you must use [insert browser name here] instead" when trying to bring up the chat window.

And then there are the recent speculations about the forthcoming enhanced VoIP support in the Flash player. On paper it looks a promising move, as the number of possible applications build on the combination of Rich Interface/Multimedia/Presence backed by a powerful interface library seems endless.
As the player already supports voice and video, tying into the emerging VoIP ecosystem is a natural extension. Obviously, the announcement has spurred several comments amongst the regular VoIP aficionados. Many, such as this one for example, mentioned the challenges related to this entreprise.

The Adobe start-up team faces quite a few challenges. For instance, it would have to support multiple VoIP protocols, and it will also have to figure out how to keep the overall size of the Flash client size small. Sources say that touching Flash Player is like messing with God inside Adobe, and the start-up team needs to figure out how to embed a SIP stack inside the player without making it bloated.

Effectively, the team working at bringing better VoIP support to the Flash player faces several challenges. But not necessarily those mentioned in this typical excerpt of the dominant VoIP meme. This is my first worry, as it sounds like a reductive fallacy to me.

The team first challenge would be to get away form the hype, and focus on building a usable, simple and standard compliant product. For sure, to be effective the resulting product will have to support multiple VoIP protocols. That said, one should remember that a VoIP communication is always the result of combining a session negotiation between parties and the transport of the voice media. If we exclude proprietary closed protocols such as Skype, which will inevitably die out, the only viable remaining standard VoIP contenders left are:

SIP and Jingle associated with SDP/ICE on the signaling side
RTP on the media transport side.

It just happens that these two signaling protocols support the same voice media transport, and the same way to negotiate it. As a consequence, only the media transport has to be integrated into the Flash player, with the signaling being provided as plugins. Using this kind of design brings multiple advantages from the standpoint of extensibility and evolution. An immediate benefit would be to allow any application to choose its own signaling and implemented media transport combination. Doing so will defuse many subjective "I don't like [insert you favorite hated VoIP protocol here]" reaction and offer the proper flexibility to help building solutions to real users issues.
Furthermore, if the transports are built into the player and the signaling available as plugins, they will be part of the player installation and not of the resulting client. As such they will not "bloat" the resulting client side application.

The team second challenge would be handling the media transport negotiation. It happens that RTP uses UDP at the network level, and is therefore handicapped when crossing firewalls and other NAT devices. To be effective, the resulting product would have to exchange voice media streams with existing and near future VoIP softphones, hardphones and IPBX. This implies that the player will have to incorporate a raw SDP transport to cater for legacy installations, as well as ICE for the upcoming generations of VoIP devices.
Several solutions have been proposed to allow VoIP calls to cross firewalls, but each class of NAT firewall requires a different technique. To complicate matters further, the different NAT traversal techniques address only one class of NAT device. For example, Simple Traversal of UDP through NAT (STUN) will not work with symmetric NATs, which you find most often in enterprise. The Interactive Connectivity Establishment (ICE) is designed to provide a framework unifying the various NAT traversal techniques. This in turn allows VoIP clients' media streams to traverse the variety of firewalls between a remote user and a network. ICE defines a standardized method for both SIP and Jingle clients to determine the type of NAT firewalls on the path between clients and propose a set of IP addresses by which clients can establish contact. ICE learns about the network topology using a number of protocols and network connectivity mechanisms, such as STUN, Traversal Using Relay NAT (TURN) and Realm Specific IP (RSIP) and deduces the various sets of IP addresses by which the devices can communicate.

The team last challenge would be to stay open minded. This is probably the toughest one. This kind of project usually involves mixing together strong business interests with strong egos. For example, maintaining and increasing the business value of existing agreements with powerful players in the telecommunication industry will no doubt have the balance lean toward SIP. Similarly, I would be cautious relying on the "teaching" provided by VoIP gurus that were brought up at baby bells, as these carriers are not known to favor the Internet. I believe only considering SIP for VoIP would be a mistake. But most importantly, the ultimate value will be driven by the way presence will fit into the resulting product. And today, nothing on the SIP side is up to the simplicity and ease of use provided by XMPP. The way they will arbitrate between the subjective interests at play will condition the success of the product. As usual the only winning combination will be the one providing a solution to the end user, without locking it into a particular way of thinking. Wisdom of the end user is certainly more real than wisdom of the crowd…

In the end, these are huge challenges, requiring wise and savvy leadership. But if they can overcome them, they could be onto something valuable. In an open standard platform strategy play, by preventing the technical hell that comes with today's VoIP clients, and offering choices to application developers, they could become the next VoIP media layer, accessible to any desktop.

When combining a standard based VoIP Flash player with libraries such as XIFF, you can just imagine the host of wide ranging and superb looking social applications it opens up. But so far we just have the XIFF library. And that alone makes it worth trying Flash based XMPP applications.

Technorati Tags: XMPP, Jabber, SIP, Jingle , Presence, VoIP, Flash, Antecipate

Presence enabled identity

2006-09-12T21:51:00.000+02:00

Giving back digital identity ownership to end users has been one of the most in-vogue identity meme of the year. But why is digital identity not any more in its owner possession in the first place? Mostly because there is no way for an application to trace the real you back and check your privileges when needed. The result is the high number of digital identity fragments disseminated all over the internet that every power user has left behind in its wandering.

An obvious first answer to this fragmentation is the re-concentration of digital identity fragments in a limited number of places. The usual advantages are put forward, mainly the convenience of near single-sign-on. On the web, several alternatives have been implemented by various types of identity brokers, which are able to provide relevant assertion about a party identity and/or privileges. But most proposed assertion systems require the end-user to trust the identity broker. And frankly speaking, I am not convinced many end users go to the length of making sure when choosing an identity broker that:

Strong credentials are enforced and required by the broker,
Credentials are securely stored in the identity broker's database.
Physical and perimeter security at the broker's point of presence is enforced.

The next obvious answer would be to re-concentrate the complete digital identity in the immediate vicinity of the end-user. After all, many tend to agree that physical ownership gives a better feeling of security…

An interesting proposal has been made in a recent series of posts, where are described the components of a reinvented internet. I have several concerns about the entire internet re-invention, but Jason is also bringing up some clever and simple ideas. In his approach, each and every user will own a domain name on which a private identity broker will be located. The proposal is interesting because an application can use the private identity broker directly as it would a web identity broker. Today's applications will also be able to resolve that private broker address just using DNS.

Although it gives a better sense of ownership to the end-user, this approach does not entirely provide a solution to the original question when the user is going mobile or when an external application requests a dynamic authorization. These use cases are no edge cases in my opinion.

Carrying a laptop everywhere may not provide the ultimate freedom. A PDA might give a better feeling, but still. Using a password from a distant terminal will work, but is not better that today's solutions. And being remote definitively decreases the ability to provide interactive authorizations. I believe real identity ownership would ultimately involve some kind of portable device, using biometrics to assess one's identity when in use. This device would in turn advertise its presence on the network. It would then be "seen" by the private server. In turn, the server would be able to interact securely with the device and retrieve whatever privileges required by calling applications.

This is the nearest I would go toward bringing together identity and presence. And why not just call it "presence enabled identity".

Technorati Tags: Identity, Presence, Trust, Digital identity, Antecipate

XMPP rings

2006-09-10T18:46:00.000+02:00

Words are words, and their understanding varies amongst those reading them. I thought I had set the context of my previous post on some the limitations of XMPP server to server communication arising from its dependency on DNS for more than address resolution. I was wrong, and Jason's follow up made this very clear.

The point I was trying to make was not related to DNS itself being a weak point in a highly distributed XMPP architecture, but rather on XMPP relying on DNS for more than just address resolution for server-to-server communication. DNS has sufficiently proven it can handle its task of name resolution.

I believe part of the evolution for the future web is in the emergence and spread of communication overlay networks serving the interest of various overlapping communities of interest. This is neither a new idea nor a new technology. The premises of this kind of organization are already at work in many GRID experiments, for example. I also believe the natural evolution for XMPP is in enabling part of this future evolution. What strikes me though is the limited number of experiments trying to use XMPP in this role. There have been several intents in the last two to three years at building some sort of XMPP based grid communications. But, to my knowledge they have not been brought to fruition.

As represented in the drawing, these architectures, that I would call XMPP rings, are made up of several nodes communication between themselves in a peer-to-peer fashion. These nodes may be either application nodes or routing nodes. Every XMPP ring domain possesses its own private addressing spaces, and communicates with the outside world through well identified edge nodes. Possible use of these XMPP ring would be large PubSub brokers' networks, distributed MUCs, or some kind of XMPP distributed hash tables.

I believe the current state of the protocol does not allow building these kinds of XMPP rings because of the way server-to-server communication works today. In particular, it would not be possible to build XMPP routers. XMPP rings routers task would be to direct traffic to a given destination using only the private ring addressing spaces. Today, the recipient of a server-to-server connection must be an end point. According to the specification, it can only receive traffic for a single DNS domain it is supposed to handle on each connection. It cannot route the received traffic to another destination because, doing so, it would not be the originating source and the destination node would have to deny the connection. This is in my opinion a limitation of the current protocol version.

Obviously the kind of architecture I am describing here was not considered in the initial standardization effort. But I would appreciate if the next revision of the standard could lift these limitations. And as a matter of fact, I believe the current servers behaviors are only specific cases of the more generic XMPP rings, which would ensure backward protocol compatibility.

Technorati Tags: XMPP, Jabber, Conversation spaces, Addressing, XMPP ring, Antecipate

The Descartes identity

2006-09-10T17:06:00.000+02:00

In a recent exchange of views, one of the participants to the discussion was "interested in hearing [my] definition of an online identity". This is certainly one of the toughest questions I have been facing. From the start, asking for "my" definition is already recognizing "online identity" as a controversial subject. I certainly have no pretence to defining what "online identity" is. But I can try to express what I know about my own identity. The only real identity I know of is what I have in my own head. We have been gifted with a conscience but unfortunately with poor means of communication. As a direct result, it makes it rather difficult to share my identity with anyone but me. This is probably the same for every human being. At every moment, I am only able to use our crude means of communications (speech, visual contact, body language…) and in turn I am only able to convey a crude expression of my identity. But this is of exceptional quality when compared to what it becomes when filtered by the Internet communication tools. The lower quality of any communication technology compared to human expressiveness makes the resulting identity perception rather approximate…

I do not have an online or an offline identity. I just have an identity…

I am hearing here and there that whatever we do on the Internet is leaving a trail and, by extension, that for example a mail address or a blog are ultimately representing one's "online identity". I certainly disagree with what I consider a reductive simplification. I never thought of this blog or any communication address I use as representative of an "online identity". My blog is a way of expressing very specific opinions on a limited number of technical topics that in other times I would have expressed using a different medium. I am concurently voicing different opinions on different subjects in many different places such as cafes, art galleries, restaurants, exhibition, streets, during business meetings or in my home. I do not have an online and an offline identity. I just have my identity.

Like many other human beings, I have been given some attributes to "assert" my identity to other beings or systems that would require it. … But beyond the 4 digits of my ATM pin code, I am not using these attributes very often. In particular, I believe "online identity" is mainly an euphemism for address handles. I consider an email address as an address handle that can be used to communicate with me. No more, no less than a post office box. Actually, at the post office, I will have to produce an attribute to "assert" my identity if I want my mail, but my P.O.Box is in no way representing my identity…

To conclude, I find today's rhetorical debate about identity which is raging in the blogosphere rather limited when confronted to Descartes' "I think therefore I am". I only have a certainty in this domain: the day I will stop thinking I would have lost my identity. This is all contained in five simple words. But Descartes had a valid excuse: he was a genius.

Technorati Tags: Identity, Addressing, Trust, Digital reputation, Digital identity, Antecipate

One of the cool things

2006-09-04T11:09:00.000+02:00

Yes, as Peter wrote, we now have all the pieces to create XMPP 2.0. And believe me, as I see it, he will for sure keep adding to an already impressive list of tribal sign posts: geo-location, mood, activity, tune, nickname. Not to mention those much more indiscrete privacy teasers: chatting, browsing, gaming, viewing…

On a side note, what strikes me is the low level of interest shown by the web 2.0 crowd in leveraging these killer features. But, thinking of it, lack of vision has always been very common in any kind of 'rush' (gold rush, oil rush, web 2.0 rush…). To be fair, it is understandable. Figuring out how to make money from something popular is a lot easier than making something popular. And using XMPP applications is not yet popular. It would require a mindset shift to go from static location based web to something more dynamic…

Going back to the protocol, these late JEPs look more like quick and dirty last hour additions than the expected result of a matured specification process. By chance, the frantic creativity that brought these many "extended social presence states" to XMPP is still reasonably limited compared to other standardization initiatives. I am just a little disappointed that these JEPs have not led to a better rationalization in the XML used to represent the associated states. After all, with all the preliminary work done by the SIP/SIMPLE working group, I believe it would not have difficult to come up with a slightly better and more extensible XML representation, using a subset of Atom for example. Another effect of the NIH (Not Invented Here) syndrome, perhaps? Anyhow, it took a year and a half to get to these PEP extended presence states written, a few days to get them through the JSF council after a rather light discussion period. It will probably take another year or so to get them rationalized when the number of wild associated namespaces would have grown to an uncontrolled level. But, as Hugh's Claymore sharp pen nicely illustrates: who cares?

Technorati Tags: XMPP, Jabber, Presence, Antecipate

In DNS we trust - too much…

2006-09-03T20:30:00.000+02:00

It sometimes takes an errand of many lengthy pieces before exposing a valuable concept. I have always wondered what is driving anyone capable of thinking perceptively to justify a legitimate desire of experimenting with new ideas. Well, this latest saga does not really answer my question. But it re-enforces my growing certainty that DNS reliance becomes a weakness and a constraint in any large distributed networking application.

The series of posts I am alluding to is a good example of the adaptive learning process happening when one evolves beyond any established technological conservatism, and makes the illuminating discovery that there might be "something else beyond (add your favorite topic here)". The associated state of excitement often takes us down blind alleys, or leads us to take shortcuts to get to approximate conclusions suiting our subjectivity. For example, the simplistic idea that a globally unique identifier (URI) will solve the "virtual identity" question is characteristic of the former. The confusion between "presence" and "identity" is more a matter of the later. So is the reliance on DNS as the global glue of our ever expanding interaction needs over the Internet.

…there is value in using a real time communication framework to give access to resources referenced by URIs…

In my opening statement, I mentioned a valuable concept. Its value is certainly not the sudden discovery that in an URI may be used to reference a resource in a particular domain of interest-As a matter of fact, I find the emphasis given by the author to this basic URI capability somewhat disconcerting. I was under the impression URIs had been invented to do just this--No, the actual value lies in the use of a real time communication framework to give access at an individual level to the resources referenced by the URIs. At last, after years of obscurantism, the light is finally coming through layers of sediments: there is more to the web than location based (i.e. URL) thinking. A small evolutionary step, but so important by the ever growing number of people embracing the same idea. Furthermore, I am also interested to see XMPP supporting this concept, as this choice further exemplify the protocol's usability beyond mere instant messaging.

The described technological implementation consists simply in a private personal XMPP server aggregating various other protocols (HTTP, SMTP) and using XMPP as a universal communication transport to access both local and remote data using URI references. The URI of choice being a JID. The implementation idea is both realistic and convincing. There is nothing revolutionary in aggregating various protocol endpoints on a XMPP server. I have done this several time in the past five years for WAP (HTTP), a few SMS centers protocols, and more recently for SIP, XCAP (HTTP) and SOAP(HTTP). So I do not foresee major difficulties beyond the time spent in his endeavor … But, by wanting to quickly get to working on the "web application aspect of the private server" the author has taken for granted that the resulting server would be able to communicate outside its private sphere. I see a few shortcomings in his approach and in the protocol that would need to be addressed for the implementation to function as described and be widely adopted.

The first major shortcoming I see is the heavy reliance on DNS, which in my opinion would create a growing single point of failure over time.
The second major obstacle, in the current protocol state, is the mandatory use of public resolvable addresses handles--which may explain why the author insists on everybody owning a "domain name".

I will try to give some substance bellow.

These private XMPP servers will be connecting to other private or public XMPP servers through server-to-server (S2S) communication. In the current state of the XMPP specification the connectivity depends heavily on DNS, and SRV records DNS extensions. The RFC mandates that inter-domain communication only takes place when the DNS host names asserted by the servers have been resolved. The connection must also use TLS, which again use domain names for authenticating the hosts. In addition, further checks must also be in place to ensure that the actual XMPP stanzas flowing between any two servers belong to the proper identified connection. By doing so, and for a number of historical choices, the current specification severely limits widespread deployments beyond the traditional "one domain equal one community" model. This has been a viable short term solution for today's limited number of XMPP servers hosting communities using XMPP clients. But in the described private server scenario, extending the usage of S2S to each and every individual user may be a stretch.

Furthermore, I doubt we will see a rapid spread of individual domain names, but I may be wrong. I am not so much concerned about scalability issues of the current DNS system than by administration issues derived from a wider usage. Moving from a specialized infrastructure product (the community domain name) to a consumer commodity (the individual domain name) implies vastly different organization and arbitrage for which the system was not conceived in the first place.

On another note, DNS administrators will eventually learn over time the benefit of SRV records to allow service discovery. But there is no guarantee they will do it quickly… Similarly, it has taken almost two years to see the first XMPP S2S interoperability testing. And it will certainly be some time until the last XMPP server relying only on S2S dial-back authentication is phased out. And this implementation requires XMPP.

These are just a few points to illustrate what makes me believe too much DNS dependency is not favoring wide adoption of individual private servers of any sort, and XMPP in particular. In the end, because any adoption process is gradual, I believe some users will probably never embrace the described technology. As a result, there will certainly be a co-habitation between a mix of private and shared servers. This simple fact implies that any proposed solution would have to address these two types of usage. The current XMPP specification is not able to provide a working solution to this requirement. I know from facts and real users' needs that the current dependency between XMPP address handles and DNS domain names is a severe pain point when deploying XMPP beyond the current single domain server communities.
I am certain many of us would appreciate an enhanced version of the protocol were servers would for example be able to multiplex several supported domains traffic on a single authenticated trusted communication link, without any of the servers supported URIs being DNS resolvable. This in turn would mean XMPP can provide some of the necessary features to create real overlay networks on top of and independent from DNS domains, with associated XMPP routers. And I believe that in the long run overlay networks with their own addressing space, connected through DNS enabled ingress/egress points are more appropriate to provide an answer to this interesting idea of private XMPP servers. And probably more.

This is probably asking too much at this point in time, when the shift from the location based to the communication based thinking is only starting… But I know for a fact building XMPP based overlay networks is not an utopia.

Technorati Tags: XMPP, Jabber, Conversation spaces, Addressing, Digital identity, Interoperability, Antecipate

Beyond file transfer

2006-08-20T19:41:00.000+02:00

Following the official release of the latest GTalk client, I decided to scratch the surface of its file transfer implementation. Thanks to Brian McBarron’s answer posted on the JSF list explaining how to capture a detailed log of the client’s operation (run the client with the following arguments: /log verbose tstamp thread file), I was able to confirm that the GTalk client is indeed leveraging Google’s implementation of Jingle to control file transfer. This endorsement by Google is another commitment to open standards. As shown bellow, the receiver party’s presence is probed before the transfer, in order to make sure the target client understands the transfer protocol. This is returned in the presence stanza’s capabilities extension. It is interesting to note that the capability is named “share” rather than transfer.

<presence to="juliet@gmail.com" type="probe" />

<presence to="romeo@gmail.com/Talk.v969557A95E" from="juliet@gmail.com/Talk.v95286273DB">
  <priority>0 </priority>
  <c xmlns="http://jabber.org/protocol/caps" ext="share-v1 voice-v1" ver="1.0.0.95" node="http://www.google.com/xmpp/client/caps" />
  <x xmlns="jabber:x:delay" stamp="20060817T19:50:07" />
  <status>available </status>
  <x xmlns="vcard-temp:x:update">
    <photo>ae825c56c617f83a577b0cff43611d2076358c20 </photo>
  </x>
</presence>

The next exchange uses the actual Jingle signaling to negotiate a transfer session between the parties. I have only shown the session part, as the point-to-point transport negotiation is identical to a voice transport negotiation. Note again the description namespace for the application.

<iq to="juliet@gmail.com/Talk.v95286273DB" type="set" id="31">
  <session xmlns="http://www.google.com/session" type="initiate" id="598724353" initiator="romeo@gmail.com/Talk.v969557A95E">
<description xmlns="http://www.google.com/session/share">
  <manifest>
    <file size="34314">
      <name>
        About.jpg
      </name>
      <image width="150" height="133"/>
    </file>
  </manifest>
  <protocol>
    <http>
      <url name="source-path">
        /temporary/6b82cd1ca2f333d99bad2ea07ce33f33/
      </url>
      <url name="preview-path">
        /temporary/9c6b15f343aaabea3c6a106eb72b4c80/
      </url>
    </http>
  </protocol>
</description>
<transport xmlns="http://www.google.com/transport/p2p"/>
  </session>
</iq>
<iq to="romeo@gmail.com/Talk.v969557A95E" id="31" type="result" from="juliet@gmail.com/Talk.v95286273DB"/>
<iq to="romeo@gmail.com/Talk.v969557A95E" type="set" id="49" from="juliet@gmail.com/Talk.v95286273DB">
  <session type="transport-accept" id="598724353" initiator="romeo@gmail.com/Talk.v969557A95E" xmlns="http://www.google.com/session">
    <transport xmlns="http://www.google.com/transport/p2p"/>
  </session>
</iq><iq to="juliet@gmail.com/Talk.v95286273DB" id="49" type="result"/>

FIle transfer is an important adjunct to Jingle, as it confirms the signaling can be used well beyond voice or other video communication. This is not revolutionary per say, as session negotiation and signaling has been around with SIP for some time now. But only proprietary extensions of the SIP signaling have been so far implemented when it comes to widely deployed file transfer. The use of Jingle bears the promise of a much wider adoption for a standard based file transfer negotiation. Obviously, this is only Google’s implementation of Jingle, but except namespaces, nothing in it cannot be made into a JEP. And this is what the authors of this file transfer are committed to do.

Coming back to my initial remark about the GTalk client’s naming this new feature “share”, I believe this update is only the pre-release of a larger scoped real-time experience. Brian’s post on the JSF mailing list gives a good explanation of the layered design applied to the file transfer application. By adopting this architecture, I believe Google is effectively enabling far more than just file transfer:

the transport protocol called “PseudoTCP” which is used in the p2p exchange is a Google re-implementation of TCP using UDP packets. The layered design would allow replacing this proprietary transport by a standard, such as SCTP, without disrupting the network stack so much.
the application protocol is HTTP enables interesting things such as download previews of images, resume transfers, compress files, etc. Without being full fledge web servers, a GTalk client becomes an important part in enabling a real time collaboration application. Linking it to a workstation’s browser through some toolbar plug-in is probably not that difficult, and would makes an XMPP backed real time photo sharing and comment experience much more compeling than their web only siblings.

Although this latest release has received unjustified bashing from many ignorant self proclaimed visionaries, I believe on the contrary that it is paving the way toward wider scoped real time standards-based sharing services for communities, open to any and all that wish to interoperate with them.

Technorati Tags: XMPP, Jingle, Conversation spaces, Session signaling, File sharing, Google Talk, Antecipate

Not microformated here!

2006-08-20T17:09:00.000+02:00

Most people naturally find it more enjoyable to speak than to listen. Which developers would not like to be known as the one who wrote this killer app that the whole company now relies on, rather than simply the guy who made the suggestion to use somebody else’s? If we are honest with ourselves, most of us, “Y” chromosomed beings, usually find it hard to admit that somebody else had better idea than we did, or did as good a job implementing it than we could have done…

Even organizations with an open mind to leveraging external ideas may simply be unaware that what they need is already available. There is very often a certain amount of "herd instinct" driving “not invented here” in these groups of peoples. Even open-source communities don't always know that what they're creating has already been done, and even if they do know, many reasons can prevent them from using an existing solution other than NIH syndrome itself. A way to diagnose NIH syndrome is to go through these other reasons and eliminate them. If none of them apply, then you are probably looking at a real NIH syndrome case! The only valid reasons are:

No existing suitable solution can be found, not even one which may be adaptable.
A close-to-suitable solution is found, but solving 90% of the problem is not sufficient. In this situation, if the "90%" solution cannot be extend or customize it to fulfill 100% of the specification, then the potential solution is rejected.
A close-to-suitable solution is found, but the work to extend or customize it to fulfill 100% of the specification is more than the work to reproduce it entirely. Again, the potential solution is rejected.
A suitable solution is found, but one that is not compatible with existing or chosen standards. This solution is rejected.

…Atom answers more than 90% of what is required for an IM logging format…

Through this lengthy introduction I wanted to express my deep agreement with Hal’s answers to the legitimate question he raised on the use of Microformats in the XMPP standard: simply put, they usually do not make sense in a real time communication context. Microformats are a typical example of very narrow minded NIH syndrome. They initialy came up to solve rendering issues in a static location based web, when information was not available in an XML form (vCard, calendar). The initial authors found smart to leverage Microformat to lessen the shortcomings of existing crawler’s technologies, and thus added keywords to published information. Again, this was a valid move for static content. But when it comes to IM logs, I believe Microformats are definitively not appropriate. There is at least one existing XML markups available that would do it better than any coming Microformat: the Atom feed standard.

If one goes beyond the word “syndication” in the standard’s name, it can easily check how Atom answers more than 90% of what is required to store and communicate content and meta-data for an IM logging system! It just need to run Atom’s capabilities through the above reasons’ list…

Atom’s feeds and entries contain three elements:

A unique identifier, which can be as simple as the URI of a blog entry or a truly unique 128-bit message stanza’s thread.
A title, which expresses a short, human readable subject line for the entry, and can be a blank string.
A time-stamp which indicates when the recorded feed or entry occurred.

A feed or entry can have multiple author elements along with zero or more contributor elements. These later elements identify individuals who might have contributed to the production of the feed or entry. Both the author and contributor elements are fully extensible, to provide as much detail about the author or contributor as deemed appropriate. Further, Atom provides a robust, flexible, and consistent content model capable of supporting plain text, escaped HTML, well-formed XHTML, arbitrary XML, base-64 encoded binary content, and URI pointers to content not included directly within the feed.

Finally for those who would be wondering about multimedia, Atom supports elaborate enclosures which have already been used in application such as podcasting, and would provide an excellent ground for future Jingle applications logging.

I am sure everyone will also understand the added value of the existing and growing support of Atom directly in the browser for rendering, and in the feed aggregators for syndication. That alone obsoletes many of the fallacious arguments used in some comments to Hal’s post to sustain the use of Microformats.

To conclude, I believe Atom provides more than 90% of what is needed for a superior IM logging format. As its transport over XMPP is already under way, it makes sense for the JSF to spend time defining a usage mapping for this new IM logging scope. Would it be as much fun as rewriting a new markup? No, almost certainly not. Would it be more efficient and cost effective? Quite certainly yes.

Technorati Tags: XMPP, Jabber, Atom, Microformat, Interoperability, Instant messaging, Antecipate

Mobile presence dial-tone

2006-08-07T23:54:00.000+02:00

The word is out about Jaiku. Some speak of “mobile social networking”, other mention “rich presence”. I would simply call it another perfect example of XMPP’s extreme flexibility and adaptability.

Jaiku combines a well conceived Symbian client with an XMPP back-end, and a web based front end service. The service is sleek and easy to register with, offer a simple and uncluttered interface, and all the necessary scripts to include your mobile presence in any web page. The client, for the time being limited to Nokia Series 60 Second Edition phones, integrates cleverly with the phone directory, converting it into a “presence enabled” directory. The client is also aware of many phone events and functions, such as the calendar. It appears the Jaiku’s team has slightly extended the XMPP presence stanzas in order to accommodate a richer set of information to includes

… an IM-style away line, your phone profile (ring volume, vibrate), location (country, city/region, neighborhood), Bluetooth devices around, upcoming calendar events, and the duration how long your phone has been idle.

Although the information released in the enhanced presence states may be perceived as disclosing a potentially large amount of your privacy, the service gives a perfect example of presence as the new dial tone. Presence being embedded in the phone directory, it is displayed whenever you want to place a call to one of your contacts.

This further reinforce, in my opinion, the advantages of XMPP. XMPP is a presence based protocol. And Jaiku is a perfect example of a non IM XMPP application natively presence enabled.

Technorati Tags: XMPP, Jabber, Presence, Antecipate

From inmates to IM mates…

2006-07-16T18:41:00.000+02:00

To put a closing section to the latest on IM misconception, I believe this piece to be particularly misleading for casual readers. After the information mashup here comes the statistics mashup. The recipe is simple. Just throw everything IM related in the cauldron, hum some incantation, and the definite truth immediately surface: “Google Talk fails to find an audience!” To be frank, I have no idea how many are using their IM service, as Google is rather secretive. I am not a Google aficionado, but something in the way the post come to this conclusion makes me feel uneasy. In the statistics:

Legacy consumers IM providers users are cited as services
Google Talk is cited as an application, and so is Trillian

In such conditions, I would have thought a more appropriate interpretation of the data to be “only 3.4 millions elected to use Google Talk client for IM”. Obviously less catchy than “fails to find an audience”…

Whatever method was used to come up with these figures in the first place, the derived conclusion is a bias on reality. The customers of all the legacy IM services, with their bright colored uniformed IM clients, are easily accounted for. In comparison, people communicating with the Google Talk service are more difficult to quantify. Nonetheless, the number of registered users for the Google talk service cannot be greater than the GMail service’s registered users. But the fact that Google’s IM services is younger than the incumbents service is not factored in. Etc… In the end, an eye catching title will certainly be simpler to create than a critical analysis of these figures.

Most importantly, this blunt statement fails to capture the fundamental difference between a captive and an open IM service. Either you listen to, communicate with, be a resource for, build trust with your users, and once you have established trust, you can build a long and healthy relationship. Or you keep your users behind bars, hopping they will not look outside, until they decide to escape. Google seems to favor the former approach. In this context, following my previous post, AOL’s biggest challenge to respond to the latest tactical move from its competitors involves deciding a drastic departure from its traditional IM model. This tougher than marying a next of kin, as interoperability would imply AIM and Google Talk becoming IM mates, creating a real opening. I doubt Google would welcome a closed partnership with any player, including AOL.

Technorati Tags: XMPP, Jabber, Interoperability, Instant messaging, Antecipate

Is Skype a parasite or a Trojan?

2006-07-15T20:00:00.000+02:00

In those days of web 2.x, I often feel that those practicing high doses of ideas mashup usually end up with brain jam. I have had found another good example with this fine piece. Obviously, there has been some discussion going on around IM interoperability lately, which in turn has brought back all the bitterness about our inability to easily and instantly communicate. But have you ever noticed how the same recipes always make for headline of “tabloid blogging”. This one starts with an aggressive title using a few recuperated clichés such a “cold war” and “détente” to awaken old instinctive fears inside the reader. The post follows with a spread of unrelated references, which relevance and validity were obviously never questioned. It goes on enrolling some fellow bloggers unwillingly, citing them partially and out of context. After this the author can pretend to pose as a pundit. Well... Some have different views and present alternatives hypothesis. I personally believe there is one approximately true statement and two major flawed assumptions to justify a lot of conjecture in this paper.

Beyond the tectonic plates’ image, declaring that IM interoperability is a business issue is probably true. Very simply, because this is a matter of toll gates, which is usually solved by a financial transaction. This is turn is business. Am I missing something?

The first flawed assumption is to present LCS as the enterprise federator, and by consequence, suggesting SIMPLE as the federating protocol. In the context of gatekeepers business, it is normal for Microsoft to claim its LCS as the universal federator for an enterprise willing to access public IM networks. This was only a matter of deep pockets and separate negotiation with every “entrenched interest”. Skimming through the recently discovered interoperability guide for LCS 2005 has somehow persuaded the author that LCS was “the” technical interoperability solution. I would only say that it may be a hasted conclusion. LCS (and other federating EIM servers) does not allow federating between public IM clouds, as inter cloud communication is specifically restricted by every individual business agreement. A second hasted conclusion is to use Google’s (very real) inaptitude at marketing Google Talk as a reason to look at XMPP with contempt. Jabberites, you would certainly be happy to learn that “with just 3.4 million [GTalk] users, who really gives a damn what you do”! Beyond the arrogance of the statement, Google is not interested in building communities; it is interested in driving traffic though its sites to increase its advertising broker’s exposure. Google has just opened the door to millions of XMPP users. This was a smart move and was received as a friendly gesture, re-enforcing their “not so evil” perception as a web company. Obviously, seeing this requires thinking outside the IM box. Which in my opinion, neither the IM incumbents, nor this author, have shown a good aptitude at doing.

The second flawed assumption is to present the Skype protocol as the “white knight” of interoperability. When writing about IM interoperability, it would not be wise nor popular to support any one of the competing incumbent public IM protocols. If so, what is left in the protocol landscape to fulfill that interoperability role for the public IM crowd? SIP has been ruled out as a contender (look at the bottom of the post). XMPP has been dismissed above. Only Skype remains to take up the role of the messiah. But now that its protocol has been hacked, I personally think Skype will pay a ransom to this group of Chinese hackers and buy them. This is in line with the recent wave of extortion based virus activity. Hacking a proprietary protocol is the just another flavor of it. But Skype could also make their protocol specification public and disable the threat, couldn’t they? They won’t do it, as they would have to admit publicly that their protocol’s client exhibits a singular cross between a parasite and a Trojan’s behavior. For the Skype network protocol, any node is a potential relay for any other node. There is nothing wrong with this design. But there is something very wrong with hiding this behavior from the end user. Aside from the questions of ethics and privacy, it steals from the user by using the computer's memory resources and also by eating bandwidth as it relays traffic via the user's Internet connection. Because it is using memory and system resources beyond the specific user’s need, the client operation may also lead to general system instability. Hence Skype’s relative reluctance to documenting the protocol...

Two approximations in one post make me feel suspicious. However, I know some peoples also define a truth as “an ingenious compound of desirability and appearance”, adding immediately that

Discovery of truth is the sole purpose of philosophy, which is the most ancient occupation of the human mind and has a fair prospect of existing with increasing activity to the end of time.

Who knows, the author may just be a philosopher in the making ;) As a conclusion, his conjectures provided sources for an additional demonstration that IM interoperability is not about technology. The solution to interoperability will never be resolved by interests entrenched in vendors’ consortia, be it Cisco behind SIMPLE, any other incumbent public IM or Skype. In the same way mail clients are on every personal computer, IM consumers and developers would only benefit when they will have the same kind of protocol: free, open and standard.

Technorati Tags: XMPP, Jabber, SIP, VoIP, Skype, Interoperability, Antecipate

IM interoperability: it’s not an IM issue

2006-07-15T14:14:00.000+02:00

Stove had it at hand, but it did not push his advantage to finish his move: interoperability is not about IM, it is about multimedia communication.

…interoperability is not about IM it's about multimedia communication…

Only in this context would a regulator (eventually) be required to step in, and force the interests at stake to “play nice”… As soon as one mentions media communication, the only business model that springs to mind is the POTS model. The toll model, with its greedy gatekeepers, has been around for millenniums. It is well known, does not require any advanced technology or an abnormally high IQ, is only based on power. In theory, it should only appeal to the most primitive societies, but there are hard facts proving the opposite…

In effect, there is no business model for IM. For what it is worth, Wikipedia describes instant messaging as a form of real-time text communication. What money is there to be made in text messaging? Same as what can be made in email. Instant messaging as a form of communication has already become a commodity. And if it had been alone, it would be using a single protocol since many years. The curse of IM lies in the bundling by the crowd of IM with presence, which is tomorrow’s real “dial-tone”. Moreover, this misconception is bi-directional. Whenever someone says “presence”, you immediately hear another person replying “IM”. And vice versa.

What is really at stake in these clouds forming is the control over presence, and by extension, over its use as dial tone to enable more efficient multimedia communications.

First of all, there is VoIP. There has been a business model for VoIP alone, related to decreasing cost. Together, VoIP and presence are much more attractive, as presence would enhance the efficiency of placing a voice call. Remember that in the current POTS, you have to actually ring the other party to find out about its availability. Establishing a voice call between two parties creates a significant load on the underlying infrastructure, even if using a separate signaling network somewhat decreases this load. This is mainly what carriers are charging you for. In a presence enabled multimedia communication system, you do not need to call the other party, as you can deduce its availability to accept your communication request from an aggregation of presence state. This approach drastically decreases the load on your infrastructure, and in theory, makes it more efficient. The carrier’s business in turn benefits from this increased operational efficiency.

Second of all, there is presence enabled marketing. Although this is still a fuzzy business model, there has been growing interest in linking focused advertising with presence to achieve really personalized content distribution. The inclusion of presence in communication devices, from mobile phones to set-top boxes, not forgetting all the connected personal computers, will allow aggregating a wide array of real-time information about one’s behavior. This alone creates huge business opportunities, when coupled with multimedia communication. By chance, the average marketer have not yet grasped the potential... This also induces a number of privacy related concerns, for which there are no satisfactory answers yet. The idea of presence enabled marketing has been in the boardrooms of the most visionary multimedia communication companies for over five years now. AOL, Microsoft and Yahoo! are not what I would call visionaries… but they have done their home work and watched their competitors. Beyond the potential, they have come to realize they could be left on the side of the road if they were to remain at stand still.

As this other post rightly describes, interoperability is not a technology issue, it is not even an IM issue. It is a wider scoped tectonic movement, where the business goes beyond the real-time exchange of text messages. I am certain the major “IM” service providers have already figured out how they will get something in return to interoperate: they will simply charge their customers for filling up their “series of tubes” with voice messages… As I said they are far from being visionaries.

Technorati Tags: XMPP, Jabber, Interoperability, Instant messaging, VoIP, Presence, Antecipate

An IM game of Go

2006-07-13T23:57:00.000+02:00

So this week has seen the birth of a limited interoperability beta test between Microsoft and Yahoo! IM bastions. The real thing to strike me in the announcement is how un-respectful it is of their respective users’ base.

The press release itself is written entirely in marketing-speak, and is rather arrogant when referring to their users. Not only do they call them “consumers”, but they try to make them, and us at the same time, believe it was so difficult to achieve interoperability. That sounds like a typical telco’s speech, don’t you think? And by many aspects it is. After all Yahoo! always believed they had built “a transport network” and that they could become a carrier. Microsoft is, well … Microsoft and has always believed it was everything. Maybe calling their users “consumers” make them feel more like real “carriers”…

For those a little familiar with the public IM context, this announcement is not about empowering their federated users’ base, but clearly aimed at isolating even more their arch rival AOL. Not directly, as one would immediately believe, by excluding it from their “interoperability”, but rather by undermining potential revenue sources. AOL is deriving revenues from charging for the access to their community of users. In certain industry verticals, such as finance or insurance, AIM is widely used, and AOL as been careful to preserve this population. It is taking advantage of it to extract revenues through “certifying” access to its private IM community. This announcement is an additional nail in their isolationism’s coffin. This is clearly what I read behind Microsoft and Yahoo! declaring that their users

…will be among the first to exchange instant messages across the free services as well as see their friends’ online presence, view personal status messages, share select emoticons, view offline messages and add new contacts from either service at no cost.

Frankly speaking, how would AOL pay toll remain sustainable in the future? Not much! You can trust all the financial institutions’ IT teams to leverage this announcement to their own advantage.

This interoperability move also provides Microsoft with a clear tactical advantage on the enterprise IM server market. They will clearly benefit from this new context and will certainly be pushing their LCS further into the enterprise. Microsoft can provide LCS connectivity to MSN, and through the interoperability agreement, will reach Yahoo! users. They already have “certified” LCS connectivity to AOL. LCS will end being the only certified multi IM networks connectivity for the enterprise. The cleverness touch resides in all this being done without infringing any right. Much unlike the use of XMPP transports in enterprise, if you see what I mean.

…there are no technical barriers to open IM interoprability between AOL and Google…

By announcing their intent long before they actually delivered, the legacy pair has again used one of the well known techniques of market control byincumbents described by Robert X. Cringely. I believe AOL is bound to move soon to counter the Microsoft Yahoo! interoperability deal. With the small investment from Google in AOL, it makes an interoperability announcement between these two other players a plausible scenario. There are no technical barriers to an open interoperability between AOL and Google, as AOL has already deployed XMPP gateways for the enterprises. On paper, it may allow a rapid reaction by AOL, but they are also known to be such slow negotiators…

You may have noticed how this annoucement is about a “proprietary” interoperability. As a matter of fact, nothing is ever said about how they technocally bridge the two legacy networks. I have seen a suggestion that the next step should be the publication of an open interoperability specification by Microsoft and Yahoo! I wonder if the author is so naïve, or was under the influence of one of his blogging “ingredients”, as to expect an “open” specification coming from these two dinosaurs. Moreover, this is not needed, as the open specification for IM interoperability already exists in the form of XMPP. Email interoperability was never achieved through “industry players”, and almost every vendor led consortium has failed to impose any long lived interoperability standard on the Internet. Is the real issue people’s short memories, their propention to re-invent the wheel, their limited conception of the Internet time-space or (name your own reason here) ...

In spite of their desire to make us believe that something truly revolutionary had been achieved, Microsoft and Yahoo! have only managed to set the foundation for a larger IM island. A 350 millions inhabitants’ continent perhaps, but an island still. Previous similar attempts, such as those by Compuserve or Genie, to deny free communication over the Internet, have failed.

Even more so in a time of user’s empowerment, in the absence of an honest voice, you’re bound to remember John Lydon’s famous words: “Ever get the feeling you’ve been cheated?” Once a fraction of these 350 millions would have realized the vacuity of the announcement and noticed the contempt with which they have been treated, it might become a heavy incentive to force Microsoft and Yahoo! to become really interoperable…

Technorati Tags: XMPP, Jabber, Interoperability, Antecipate

IMteroperable? isn't it amazing, dear?

2006-07-13T14:23:00.000+02:00

What is really the best in Microsoft and Yahoo! interoperability announcement is the part, were the customers of the two services:

will be among the first to exchange instant messages across the free services as well as see their friends’ online presence, view personal status messages, share select emoticons, view offline messages and add new contacts from either service at no cost.

So, paying interoperability was amongst the options? Such an unashamed attitude is simply amazing.

I leave you to read the rest of this marketing verbiage and discover how 350 millions where left out of a vast commodity service offered to the XMPP federation for over five years now. You will be surprised to discover that Microsoft and Yahoo!

are proud to deliver this latest advancement in IM services that empower people to communicate with virtually whomever they want, wherever they want and whenever they want.

and that the latest advancement they are referring to is simply that

Consumers worldwide from Microsoft and Yahoo! will be able to take advantage of IM interoperability and join the limited public beta program. They will be among the first to exchange instant messages across the free services as well as see their friends’ online presence, view personal status.

Beyond the fact it looks like an April’s fool day’s press release, I am just wondering how, in our days of user’s empowerment, 350 millions still bear that kind of arrogance from such dinosaurs. But you never know, Microsoft and Yahoo! may well push it further and claim a patent on IM interoperability by tomorrow...

Anyway, this is again a reminder of a sad reality. We find today a bunch of IM services attempting to emulate the grotesque attitude of wireless carriers. Walled gardens are not only alienating, they are essentially hostile to the customer. Customers, beyond an enormous frustration feeling, should have a greater say in the matter. It will be interesting to watch how they will assert their rights, because, from the tone of this announcement, the IM providers are in a rather arrogant mood.

In the end, what worries me more is the flabergasted attitude expressed by this kind of post. But when someone describes Trillian or Adium as services, no wonder it also writes “IM interoperability took so long that I thought it was never going to happen”. But today everything has changed. Isn’t this really an amazing world?

Technorati Tags: XMPP, Jabber, Interoperability, Antecipate

MSRP: Managing Severely Retarded Protocol

2006-07-09T17:39:00.000+02:00

The messaging and presence protocol space is a good miniature of human passions. It exhibit this exquisite duality you find in those good old duck dodger’s cartoons, between those wanting to master the world and those wanting to save the world.

Behind the smoke screen created by using words such as “open” or “simple”, the sipping working group has been actively busy coming up with yet another messaging protocol. And guess what, this protocol is so superior that “in other words you can build a skookum Instant Messaging application using this technology”. What a world savior!

What really struck me in this article is the blunt announcement that “SIMPLE is primarily a done deal from a standards perspective”. Anyone looking at the dependency list for the 3GPP mobile network will somewhat play down this affirmation. There are a lot of non standard drafts left in the list, with a dependency stated as critical, that are stalling many technical implementations. In particular, several of these dependencies relate to XCAP, the new form of XML query devised by another “would be master of the world” recently recuperated by Cisco. The article goes on saying

The exceptions are to do with some ongoing work in putting together the last of the framework that’s needed for a user of SIMPLE to be able to tell a service provider what their preferences are on how people can reach them. Which are the last parts of the mechanism that let XCAP (XML Control Access Protocol) work. The XCAP data formats are all well defined and the protocol for the most part is well-defined. The one corner that we are working out right now is the modification of partial documents in XCAP.

There are a lot of conditionals in this explanation, don’t you think? To make it short, XCAP does not work yet. I believe its only “raison d’etre”, beyond the “NIH syndrome”, is the blatant inability of many in the SIP world to see beyond HTTP like request response protocols. To their defence, I would only say that, to those wanting to copy the POTS features, HTTP looks definitively like a very advanced protocol. But I maybe biased. In reality, disguising HTTP into XCAP may simply have been required by the inability of many mobile phone to support anything else than HTTP. If I remember well, in the beginning, J2ME and Symbian (two other world saviors) only had HTTP as their communication protocol. Not even a socket was exposed… One way or another, this is part of the ongoing refusal by most telecom players to consider a customer anything but a lucky “user” of the wonderful services they provide.

Going back to implementations, I have a compasionate thought for all the bright developers trying to make an instant messenger out of SIMPLE, XCAP, and now MSRP. But the gloom is somewhat brighten by the nice discovery that

… if we were in an IM session and I had a picture I wanted to show you. I could do that and we could share that image dynamically without interrupting the Text session plus associating that image with the session when we were done.

Don’t you think this alone is of a nature to create real value and reassure the developers about MSRP? Not long ago the excellent XTen client product team was producing sometimes more than a protocol build every week in order to keep up with the changing specifications. I am afraid this is not likely to change soon with the introduction of this new messaging transport.

Is creating new protocols really the way to promote open and inter-operable communication spaces? I frankly doubt it. But as I said at the beginning, there is no fun without would be “world masters” and would be “world saviors” whacking each other.

Technorati Tags: XMPP, Jabber, Interoperability, MSRP, Antecipate

FreeSWITCH has got a clue

2006-07-09T15:42:00.000+02:00

The FreeSWITCH project is reaching maturity, and I whish they manage to get their first release out to be presented at ClueCon.

From what I know of its architecture, it possesses all the ingredients for a real internet wide distributed voice system. As such I believe FreeSWITCH would have to be seriously considered as the voice platform of choice to complement XMPP. The philosophy driving their concept of distributed platform bodes well with the XMPP federation cloud. But above all, beyond the necessity to provide early solutions, they really understand the difference between Jingle and Google Talk.

I just hope they fix their registration procedure so I could get a build to run on my Windows server…

Technorati Tags: XMPP, Jingle, Jabber, VoIP, IPBX, SIP, Session signaling, Antecipate

Simple factor is better than two-factor authentication

2006-07-09T14:33:00.000+02:00

This article is spot on looking at how the two-factor authentication generated hype is hiding away simple and inexpensive solutions. The new buzz phrase in corporate boardrooms is “two-factor authentication is the only adequate control mechanism for internet-based products and services such as online banking”. In reality, I would rather say that being in the boardrooms makes upcoming two-factor authentication inadequate. The ineluctable result would be another massive money influx at keeping alive outdated thinking about identity. Many privacy and security professional say the induced costs and operational challenges to implement two-factor authentication on a large scale are making it time to reassess the situation. Their reasons are summed up in two main questions:

What new risks have been discovered that need to be addressed?
Are there other ways, besides traditional two-factor authentication, to counter these risks?

The author give the standard answer to the first question:

that the purpose of the second factor of authentication is to compensate for the weaknesses of the first factor, the password. Weak passwords can be cracked with free software available on the Internet; they can often be discovered inside files stored on the network or people’s laptops, or on sticky notes left inside desk drawers; and they can be solicited through social engineering and phishing e-mails.

The article goes on describing different alternatives addressing the second question. But I believe it does not capture the real reason why the question were asked in the first place. In essence, these questions are telling us that password authentication is inefficient because passwords are available all over the corporate and extra corporate spaces. They nevertheless fail to analyze this finding beyond the mere need to supplement it by an additional control.

If password based control has become so weak, it is because of its inadequacy with human behavior. Passwords would bring the expected level of control when only used by machines. Machine are natively built to understand and remember 256bit hash values, not human beings. On the other hand, photo passwords as described in the article will perfectly suit a human mind, and discourage even the most powerful image recognition algorithms.

Forcing a machine semantic on flesh and blood never works. But I doubt this is common wisdom in the boardroom.

Technorati Tags: Identity, Digital privacy, Digital identity, Antecipate

Live pains on sight...

2006-07-09T13:36:00.000+02:00

There have been scarce mentions of the rollout by LiveJournal of an XMPP based instant messaging service. Beyond the expected voice, I have found very few references to the announcement outside the community, and when they were, they had very specific topics of interest.

…the absence of smart integration between applications and XMPP servers is a major bottleneck to a wide adoption of XMPP…

This is somewhat of a concern, as the expected viral endorsement of XMPP is still far from taking off. Obviously, any smart and business savvy community wanting to offer instant communication to its members is better of choosing XMPP as a protocol, rather than developing its own. Google did it, and I have previously exposed some of the business drivers behind this choice. The same applies for LiveJournal. But beyond the marketing numbers claiming an additional 10 millions XMPP users, what is the reality.

LiveJournal has taken a clever approach to managing its IM users’ rosters, which is very similar to what is found in corporation. They have come up with a very controlled process leveraging the existing user base, taking an integration perspective. This is in my opinion the reason why they created their own XMPP server, rather than adapt an Open Source one. I believe the absence of smart integration between applications and XMPP servers is the weakest point of the current wave of Open Source servers. And it is a major bottleneck to a wide adoption of XMPP as an application messaging transport, much more than reliability. Application integration is not about allowing low level access to a database or a directory, which is the bare minimum a server must provide. Application integration means enabling server to servers’ communication at the application level. In the current Internet context it translates into making XMPP servers natively understand HTTP, and Web server have integrated XMPP transport.

LiveJournal is rolling out its own vision of XMPP. I understand perfectly the need for different communities to leverage their own specificity, but I also believe it must always be done without lock-in. Give an end user all liberty to leave at any time, taking with her all her belongings, and you will keep her for as long as you whish. Base your service on wrong assumptions, or tweak the standards, and you create an uneasy feeling. Creating an uneasy feeling is exactly what this statement is doing:

We have SSL support, but we're not enabling it, at least not right away, but the auth is challenge/response w/ anti-replay stuff in it, so people can sniff your conversations, but not your login info. So SSL isn't required. With iChat, you have to explicitly turn it off. Justification: lot of CPU overhead for little gain, especially as clients often use OTR for end-to-end encryption.

Support of TLS is one of the soundest requirements of XMPP. The argument for not using TLS are very light.

Mentioning CPU overhead is irrelevant with today’s workstations. On mobile clients it could have an impact though. With the concurrent connection figures announced for djaberd, I have the feeling the issue is more about server side scalability. Without TLS, connecting to the LiveJournal service from an OpenSource client will create another of these “unnecessary pains” Justin has been rightly moaning about recently.
The second issue resides in naming OTR as the justification for not using TLS. In the current state of XMPP, this is simply an error, and will remain so until we have enough clients supporting JEP-116 in the loose. And even then, end-to-end encryption will by no mean be a reason not to use TLS.

Creating islands in the communication space is a sensible and realistic approach. But reducing the inter-islands permeability to the lowest common denominator is still legacy thinking.

Technorati Tags: XMPP, Jabber, Interoperability, LiveJournal, Antecipate

What is so advanced in AMQP?

2006-07-02T18:50:00.000+02:00

As a matter of fact I was looking at posting on AMQP, but Nolan has beaten me to it. Nevertheless, I believe there is more that hope to see XMPP used as a mainstream application messaging protocol before 2011. It only need to addresses a few additional features found in AMQP to be perceived as a valid contender. Let me explain my position by analysing the claims made in the announcement. Starting with the marketing blurb, the announcement explains in preamble that AMQP was developed

In response to internal requirements, market demand and partners' electronic trading needs, the contributors are collaborating on specifications for defining and building messaging infrastructure that is broadly applicable for enterprise use, totally open, platform agnostic, inter-operable, and which aims to provide developers with simpler and more powerful ways of constructing messaging dependent applications.

I doubt anyone would ever use the world “retarded” in a new protocol name. Similarly it would be very inappropriate to admit that a new protocol is not driven by a real world requirement, does not address a market need, would only be implemented in a narrow vertical community, as a closed protocol, running on dedicated hardware and providing a more obscure API to developers. In the end, AMQP is just another message queueing protocol incarnation, for a very specific vertical: the finance industry. Is that enough for being advanced?

Let’s now compare the two protocols models. XMPP and AMQP use a similar model that defines a server's semantics explicitly. AMQP explains its approach by “interoperability” which as been part of XMPP from the very beginning. Both models specify a modular set of components and standard rules for connecting these. AMQP defines three main types of components, connected into processing chains in a server to create the required functionality:

The “exchange” component receives messages from applications and routes these to message queues, based on various criteria, usually message properties or content;
The “message queue” component stores messages until a consumer client application can process them;
The “binding” component defines the relationship between a message queue and an exchange and provides the message routing rules.

This is known territory for anyone familiar with message middle ware architecture. An AMQP server is nothing but a specialised email server, with each exchange acting as a message transfer agent, and each message queue as a mailbox. Bindings define the routing tables in each transfer agent. Applications “publish” messages to individual transfer agents, which deposit the messages into the appropriate mailboxes. Other applications “consume” message by taking them out of the mailboxes. Again just another expression of the classic concepts of store-and-forward queues and topic subscriptions, with a zest of on-demand message queues and message queue forking.

XMPP pubsub extensions already address many of these features. Persistent nodes play the role of AMQP store-and-forward queues, instant nodes can be used for on demand AMQP queues. But AMQP also makes way for content-based routing, explicitly using message attributes. XMPP does not provide a similar explicit way to define content-based routing, as the pubsub extension leaves this decision to the implementation.

If we now look at the transport protocol, AMQP is defined as “a binary protocol with modern features: it is multi-channel, negotiated, asynchronous, secure, portable, neutral, and efficient.” This definition alone let me believe that XMPP was very “advanced” and has possessed many modern features for a long time now. From this phrase, the only word that can lead to possible counter arguments is “efficient”. And from my perspective, this is even subject to appreciation.

The AMQP protocol defines a transport layer and a functional layer. The functional layer comprises a set of commands which can be mapped to the XMPP pubsub extension without too many difficulties. The transport layer “handles channel multiplexing, framing, content encoding, heart-beating, data representation, and error handling”. Well, apart from “heart-beating” which is sometimes the cause of heated debates on the JSF mailing list, the rest of the functions is present in the current XMPP standard. What is not yet in XMPP, though, is an appropriate reliability mechanism. But the subject gives rise to similarly heated threads at the JSF.

In the end, paraphrasing Nolan, I totally agree that:

AMQP offers point-to-point, publish/subscribe, and many-to-many messaging. It's a binary protocol which could provide a slight increase in speed over XMPP, but it lacks a standard message body format, presence, and everything else the JSF has pushed out. Not to mention that AMPQ still hasn't reached version 1.0 yet.

In short AMQP arrives too late, but is by no mean advanced.

Beyond the technical aspect, I also believe AMQP’s announcement is the implicit recognition of the larger space XMPP is bound to take as the real-time, presence enabled messaging protocol. I am basing my analysis on these very simple facts. AMQP is a tentative answer to the threat imposed on incumbent messaging protocols developed for the financial industry by open and extensible protocols such as XMPP. The advent of cheap, standard based, alternatives to proprietary messaging systems opens large breaches in the positions of first tier vendors such as Tibco or IBM. It threatens even more the second tier vendors such as those involved in AMQP. In effect, I believe the risk is greater for the second tier, as displacing the first tier will certainly take longer.

In term of business solutions, 80% of the financial message based communication can be handled through “unreliable” messaging protocols. This has been a strong driver behind the very early adoption of IM by the financial industry to conduct many communications leading to money transactions. I believe XMPP could easily add the required reliability to cater for a great part of the remaining 20% in communications. And I am not mentioning the other advantages that can be derived from XMPP’s embedded presence support.

As a matter of fact, I do not believe AMQP will ever achieve its dream of dominance, simply because it is promoted by a software consortium. Despite known procedural problems, the IT industry has a strong tendency to rely on consortia to produce technology. Web services, middleware’s current silver bullet, represents the archetypal example with its internal fighting, fragmentation, lack of architectural coherence, design by committee, and feature overload. It seems inevitable that Web services’ history will resemble its CORBA ancestor. An alternative exists with open source standards. At the heart of these alternative practices are two essential prerequisites: cooperation and trust. Without cooperation, an evolutionary process cannot exist. Without trust, no common experts group can act as an ultimate arbiter. This is precisely where software consortia find their limitations. Putting customers and competing vendors into a consortium and expecting them to come up with a high-quality product is naïve. Commercial realities ensure that cooperation and trust are the last things any participant will care about. Naturally, software consortia contribute to an evolutionary process just as much as open source projects do. But the final direction will always be set by the customers in the consortium with their wallets. For those acquainted with the financial industry practices, this role is usually not benevolent...

In the end, I believe the AMQP announcement has been driven by the same “Fear, Uncertainty and Doubt” (FUD) practices described in “Accidental Empires”. In chapter 14 of his book, Robert Cringely describes techniques one can use to control the market:

Announce a direction, not a product, and people will stop buying competing products because you’ve just told them they’re the “retarded” way of doing things.
Don’t support anybody else’s standards and make your own.

When analysed in context, AMQP represents a strong endorsement of XMPP as a viable technology. In my opinion it also highlight the need for application specific extended specifications build on top of existing XMPP extensions. In particular, instead of defining a “generic” reliability mechanism for XMPP, it might be more efficient to define context related extensions. Don’t you think there is a great probability for “reliability” in the financial industry to bare a different meaning than the same word in another industries?

Finally, again paraphrasing Nolan, “we could learn a few things from them, like their requirements.” I entirely agree users’ requirements are always worth reading. We could probably also get these requirements directly through the main JSF’s sponsor. After all, isn’t JP Morgan Chase one of their blue chip customers? This to emphasised Nolan’s plea for advocacy in this space. But in my opinion, advocacy must move well above the John O'Hara or John Davies level. To a level that understands you can get the same feature set as offered by proprietary messaging protocols for 20% of the cost… This is a message the financial industry usually receives well without a “reliable” protocol.

Technorati Tags: XMPP, Jabber, Interoperability, AMQP, Antecipate

Left to the implementation

2006-06-29T23:24:00.000+02:00

Having looked various experiments in the field of digital identity, I recently decide to use an interesting contact filtering feature offered by certain i-brokers. This service allows you to filter out only dully identified communications addressed to you from a web page link. As I was not interested in joining any particular community, I decided to create an i-name on a generic i-broker. The registration process went almost well until after giving my payment details the system spat and “application error (Rail)” page after briefly showing a receipt page with a transaction number… So much for my financial records.

Not stopping at this little detail, I logged into the i-broker using my newly acquired i-name, in order to setup the contact service. At this point the system warned me that the i-broker “is not quite ready” and as a consequence they “plan to have the new Contact Service up and running very shortly”. As a matter of fact I would have appreciated being given this information as a note on the registration page. This notice may have resulted in me deciding to postpone the registration process.

That made two disappointments in a row. The i-broker service had been through a beta period not long ago. So, I thought it worth sharing my experience with the i-broker team. I happily clicked on the “contact us” link, which brought me to a “this page does not exist” warning… Interesting navigation. At that point I went back to the previous i-broker beta site where the contact page was available. Obviously, the form to contact the technical team was using the “contact filtering” service whic was available in beta. The form provided an option to use my newly registered i-name. I duly reported my ordeal and submitted the form. At this moment the system replied telling me the i-name I just registered and logged in with was unknown … I was under the impression i-names’ major advantage was in using XRI to be resolvable everywhere.

Beyond the early disappointment created by this experience, I believe there are a few lessons to be learned. When deploying a public facing application, I believe it is paramount to provide a customer:

An easy an enjoyable user experience,
A clear indication of the features available at this moment,
A robust application framework rather than the latest hyped tools,
A working demonstration of the services provided.

Failing to demonstrate these simple ingredients of any web application is in my opinion one of the major cause of service disappearance and bad reputation. I often read in standards or specifications that “it is all left to the implementation”. This is excatly the point, and the responsability of the implementers. I personally would not like to see i-brokers disappear so soon.

Technorati Tags: Identity, Digital privacy, Digital reputation, Digital identity, Antecipate

Roster remoting

2006-06-28T23:34:00.000+02:00

But how does Romeo knows “a2ff356” is in fact Juliet? That was the offline comment to my post about XMPP transports addresses. Oviously the built in “name” attribute that is part of the roster management syntax can be used to initialize this information. It could hold Juliet’s address handle in the external network, or a nickname if the networks supports both address and nicknames. But none of the current transport implementation will allow to always force these parameters to their proper values, or allow them to be reset on demand.

Nonetheless, I am toying on this blog with practical ideas and suggestions that can be picked up and build into solutions to enhance the XMPP protocol functionalities. From the discussion thread that followed this question emerged a simple concept: why not let the transport manage its own part of an user’s roster?

Current XMPP servers’ implementations have a very centralized way of managing a user’s roster. This architecture design has led to many protocol extensions to accommodate a transport’s role as an external user proxy. In effect, a transport “impersonates” an XMPP user into a different communication network. It provides the appropriate communication and presence translations, as well as an address handle mapping between the two communication spaces. The main requirement for using a transport is possessing an address handle in the target communication space. An XMPP transport to Gadu-Gadu would require the XMPP user to use a Gadu-Gadu ID in order to be recognised as a proper Gadu-Gadu user. If the XMPP user has used the other communication network before moving to XMPP, it will almost certainly want to carry over its previous contact list. If the XMPP user just wan to use the transport to communicate with a different network, it will certainly want to add new external contacts to its roster.

…what if the transport itself becomes responsible for managing its part of the user's roster?

Every transport to date has been designed around the centralized roster concept. Earlier on, a transport was silently updating the XMPP user’s roster at registration time. More recently, the XMPP protocol has been augmented to cater for the kind of bulk roster addition a transport was likely to produce. Now, imagine for a moment that the transport itself becomes responsible to manage its part of the user’s roster. In effect, the management of MSN users would be done by the MSN transport, the Yahoo! Users roster would be handled by the Yahoo! Transport, etc… In this architecture, the transport is responsible to provide the answer to the initial question. The answer would be easily carried in the name attribute of the roster result. The transport could offer administrative options to allow/prevent users to change the external network nickname and maintain a tight coherence between the XMPP and the external contact list.

In addition, delegating the roster management to the transport would also decrease the overall traffic between the home XMPP server and the transport, providing a specialized XMPP compliant distribution list for presence. An implementation allowing “roster delegation” would have to enforce an adequate level of trust between the transport and the user home server. This trust could result from two different contexts:

If the transport is a component of an XMPP server, then the trust would result from the configuration of the server and the component.
If the transport is a remote service provided by a different server, then the trust would be established through Mutual TLS authentication between the transport and the home server.

In the created trust domain, the home server would be able to decide to delegate the roster management to the transport. More generally, it is possible to extend this concept to any service providing a contact list management of some sort. This would extend XMPP using the traditional “simple client, complex server” approach. From a client perspective, nothing has changed. The client issues a roster request to its home server and receives a result. The way the roster is managed is entirely dependant of the server implementation. It is the server’s responsibility to discover “roster delegation” support and to aggregate the various roster parts into a complete roster result. The decision to use delegated roster management can also be coupled with the level of trust provided by the remote service. This would allow a server to opt out using “roster delegation” if the target system does not comply with a defined trust level, or reputation, although it provides the delegation feature.

Technorati Tags: XMPP, Jabber, Interoperability, Addressing, Conversation space, Trust, Antecipate

Addresses are for routing

2006-06-26T00:39:00.000+02:00

I was reminded by a reader's comment that address handles are still given properties beyond their only designed role: addresses are for routing. That is, routing only. Any attempts at loading an address handle with an additional meaning is only creating confusion. Address handles are not identity tokens. Address handles must not provide application logic. This bad practice is the best way to create lock-ins and decrease applications' scalability and extensibility. An address handle must be used in a single context: to indicate the destination of a communication.

This foreword done, the comment originated from the need for proper conversion rules when translating addresses from a communication space into another. The example was taken from the current XMPP transport practices, where the non-XMPP address handles are encoded as the node part of a JID. I believe this practice is wrong and does not possess any good technical grounding.

In an XMPP addressing space, a component such as a transport will have a JID comprised of a domain part only. Let's say "transport.montague.net". If a user on the XMPP side of the transport has contacts in the legacy side, the common practice is to apply an encoding logic on the legacy address to build the node part of a JID representing that contact in the XMPP world. The result might look like "juliet%capulet_it@transport.montague.net". The issue with this conversion lies in the resulting urge by many developers to use this "logical" encoding of the node to derive a meaning in a client for example. If the contact JID had been "a2ff356@"transport.montague.net" the programmer would never had used the node for anything but its role. The opaque node keeps all the routing properties of an good address handle, which in this case requires that a stanza using this JID be routed to the "transport.montague.net" service. It is also easy to see that this approach is completely independent of the target legacy system.

Introducing a logic in the node encoding of early transports has

induced developers to reverse this logic inside their code, creating a de-facto legacy inside the XMPP clients and transports implementation,
imposed at a time different encodings because the target legacy systems have different addressing spaces syntax.

Lastly, I believe there is no good reason to use a logical encoding of the JID's node for legacy contacts. Finding the contact's address can be achieved by looking-up the opaque node value in a cached table to obtain the legacy address. In terms of performances, I believe the time difference between a lookup and a decoding does not count much when compared to the actual transport wire transmission overhead.

Technorati Tags: XMPP, Jabber, Interoperability, Addressing, Antecipate

Usable interoperability

2006-06-25T14:19:00.000+02:00

The IEEE directory describes inter-operability as

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

Well, if we take that definition into the human communication space, we could say that speech allow a good level of “protocol” level inter-operability. When we add the knowledge of a language, then we can exchange and hopefully make use of well-formatted (syntax) and meaningful (semantics) messages. What is in my opinion a little flawed in the IEEE definition is the part about usage of the received information. I believe inter-operability does not have a meaning outside the scope of a particular application domain.

In my previous post, I stated why I do not find great interest in the SIMPLE/XMPP “inter-operability” draft proposal. To re-enforce my previous position, I would say the draft describes proper messages syntax, even a beginning of shared semantic between the two protocols, but completely fail to put the inter-operability in context. Without the intimate knowledge of a shared human language, one can receive the perfectly valid speech flow without being able to use it. A bit similar to listening an opera where a Spanish tenor and an Italian diva sing in Russian. They exchange perfect syntax and semantic but with a limited use, mainly providing marks for the other to respond. Don’t you think we may be missing, like the spectator of the opera, a great part of the meaning?

Technorati Tags: XMPP, Jabber, SIP, Interoperability, Addressing, Antecipate

Unnecessary "interoperability" drafting

2006-06-24T22:38:00.000+02:00

After some time out of the communication realm, I will comment on the presentation of an Internet-Draft that defines how to enable basic interoperability between SIP/SIMPLE and XMPP.

It is funny how interoperability and federation between different communication media is always reduced to "mapping". This is once again exemplified by the draft proposal trying to explain how to achieve this hypothetical interoperability. From the architectural assumption, we already get the feeling this is too good to be true. Being amongst the very few people having implemented a federation between these two protocols, and probably the only one having designed a native SIMPLE connectivity on an XMPP server, I can tell you this is slightly more complex than the draft describe…

The draft goes to great length to describe how to convert between a SIP URI and an XMPP JID. This is an excellent and accurate work, and its undisputable merit lies in providing in one single document a thorough description of each address' syntax. But in real life, what are the chances for the addresses in these two communication spaces to require direct translation?. Not very high. Why would the syntactical similarity between a SIP URI and an XMPP JID provide a guarantee that the same address must be used? After all, we do not translate JIDs directly to email addresses, nor SIP URIs either. We do not translate AIM screen names to SIP URIs, nor to JIDs. In the real world, we perform a lookup of one communication space's address in the other... We use directories to achieve the "mapping", rarely direct translation. The only case where this would be used is when SIP/SIMPLE user agents connect directly to an XMPP server, which is somewhat uncommon.

Where the draft is not up to the task is when trying to map the long term presence subscriptions of XMPP with the short term subscription of SIP. It is all fine when there are no existing subscriptions form either side. In this case, translating an XMPP subscription into a SIP SUBSCRIBE would provide the desired effect. But only the first time. The next time, the permanent XMPP subscription will trigger a presence stanza, instead of a subscription stanza. Nothing in the draft addresses how to handle this difference. In SIP we have a well delimited publish-subscribe behaviour. In XMPP we have a variable context behavior: before and after subscription.

The draft indicates that the XMPP subscription could be terminated by the SIP subscription. But this is not realistic. From an XMPP user's stand point this would mean re-subscribing to the contact on every login. And further on, this would force the XMPP user to accept a SIP contact's subscription for every contact’s log in.

Working the other way round is easier, as it is always possible to translate a SIP SUBSCRIBE into an XMPP subscription. If no subscription exists for the SIP contact, the subscription stanza will be sent to the XMPP user's client if and only if the user is online. If the user is offline, the subscription will be stored by the XMPP server, awaiting the user's acceptance. So the gateway will have to deal with this case, which is not described in the draft. Similarly, the draft does not handle the case where the XMPP user refuses the SIP contact's subscription. In SIP, if a subscription is refused it translate into an error response. The gateway would have to be aware of the presence state of the XMPP user to take the right decision. This asynchronous handling does not easily "map" with the request/response nature of SIP. Following the proposed scenario, the gateway would have to maintain a copy of every user's presence. This is both inefficient and non scalable. And again not very realistic.

As said above, SIP presence is based on short lived publish-subscribe, initiated by the requesting user agent. This is the opposite of XMPP, where the server acts as a proxy for the client user agent. SIP relies on expiration to cancel subscriptions. XMPP sessions do not time out. SIP is connectionless, whereas XMPP relies on the client connection state to deduce the end of a client session. All these fundamental differences are not highlighted in the draft, and as a consequence the cases described are both superficial and incomplete.

In the end, I find no real value in issuing a document whose only real complete description is in highlighting the difference between XMPP and SIP address handles representations. It is also detrimental to reduce interoperability between the two protocols as a simple translation between message types. None of the real issues of application interoperability are addressed in this document which looses all its substance, and by consequence its necessity. Beyond having “the longest title in IETF history” I believe this draft would be better off retracted. This energy might have a better result applied to the Jingle specification…

Technorati Tags: XMPP, Jabber, SIP, Presence, Interoperability, Addressing, Antecipate

Water does not have an history

2006-06-24T20:14:00.000+02:00

As human beings we place absolute on the scale of our desires… We aspire to absolute references, because we desire comfort and satisfaction, "we want things in our life that don't change". In our relationships we try to relate to others through the best absolute reference we can. Through naming.

We humans name things because speech is our principal mean of communication. Other species rely on smell or sound to provide a reference, we use names. And naturally we will use these names to identify other persons.

Now that we have extended this concept into the digital world, we tend to continue using names to provide identity references. Absolute references. And we are making a mistake.

Octavian has ended the late Roman Republic, and created the early Roman Empire under the name of Augustus. Popes change names when they are elected. One changes name to "begin a new life". In every case, different names refer to the same individual. Octavian and Augustus are the same person. Apart from the color of his clothes, the pope is the same person before and after his election. Only the reference has changed, as the context in which the name is used has changed. And these references point to the same identity. The name is used to fix a reference in a particular context at a particular point in time. It is bound to evolve over time.

Translating this into the digital world, mapping identity and globally unique identifiers becomes an utopia. It simply denies the possibility for the reference to change. In the real world, even the 'baptismal' naming we receive on our birth is a contextual relative reference. The probability for it to change is lesser that other identity attributes in our life, but it may vary. Furthermore, this reference is only relevant in the context of using speech as a mean of communication. If the communication changes, the way we reference an identity also changes. When we see an acquaintance on the other side of the street, we are able to identify the person even without remembering its name. Hearing someone's voice over the phone gives us a different way to identify the person. Other context, other reference.

In the end we have to be careful when drafting digital systems dealing with identity not to let our aspiration for comfort reduce the multiple facets of identity to a minimum incompatible with the complexity of its expression. Naming an identity in today's' digital world comes from the way the technology works. We are just trying to fit the foot to the shoe here. This is a huge scope reduction!

As explained by John Burgess, names can convey meaning as well as fix references

… given the truth of Avogadro's view that water is the compound H2O, it could not have been anything else. A world where a substance of a different chemical formula filled the lakes and rivers would be a world where something other than water filled the lakes and rivers.

But in comparison with persons' identity, water does not have an history.

Technorati Tags: Addressing, Identity, Digital identity, Trust, Antecipate

A vulgus pecum SLA

2006-06-23T17:39:00.000+02:00

…Identity control by the end user includes expressing the risks incured by its misuse…

The recent public release of Google spreadsheet has brought to surface worries and concerns for corporate data protection. In short, with this application, Google will be opening yet another hole into the already permeable membrane protecting corporate data.

Some may wonder if Google offers a service contract to protect data with Google Spreadsheets… So far, the agreement is limited to a software license agreement that disavows liability. No doubt there will soon be an option for corporate users who would want more reassuring terms, based on policy and regulatory requirements. This is usually referred as a service level agreement. In the business world, this document is used by an organisation to expresses its control objectives or risk losing control to a service provider. When the providers understand what is expected of them and agree to it, then and only then does it become appropriate to allow them to hold and manage sensitive data.

The important aspect of this regulation of the data handling comes from the origin of the SLA: the organisation is the one expressing the required level of control and the liabilities caused by a loss of control. And everyone agrees to consider this to be “best practices”. Then why on earth couldn’t we have the same for our individual identity data? Empowering the end user and giving him the ability to “regain control and express incurred damages” over its identity would also mean giving the user the possibility to define the terms of its expected service level agreement. Identity, its associated and its perception are entirely contextual. Only the identity’s owner is able to assess and express the real risks incurred by a misuse of this information. In effect, it is the service provider that should have to abide by the “vulgus pecum” SLAs! Not the end user agreeing to the provider’s often flawed and limited “privacy” policy. But this would be in an ideal world…

Technorati Tags: Identity, Digital privacy, Digital reputation, Digital identity, Antecipate

Me Too, Me Also, Me Copy

2006-06-23T16:10:00.000+02:00

Andy Abramson has a story about Microsoft having a story on “presence enabled” communications. Andy Abramson is a little late on this one… I wonder why reactive experts are only blattering about the visible. And why above all, do they have hair thin memories.

The actual brilliance is not in Parus for using the phone call result as an indicator. Not using a dial tone when you are in the phone business would be a crime. The brilliance is not in Iotum for adding a web interface to a server based preference store and filtering the call session requests. I have explained in earlier post why I have always believed presence to be the next dial tone, and why Iotum is still short of providing the expected value. Citing these players is only a justification for a post about Microsoft being a little heavy on the dinosaurs scale. But everyone knows this, so much for the Me Too.

What Andy is missing about Microsoft is that they presented their road map and they are just executing on it. Everything about “presence enabling” communications and office application was written down when the “Real Time Communication” server was unveiled a few years ago. At the time, I agree, Microsoft was not making a great innovation. It was just building up the ideas laid down by the PAM (Presence and Availability Management) forum on how to leverage presence states and user based rules to derive an “availability”. That may not have been brilliant, but it shows that someone had picked up the idea and seen the potential. Andy did not, as far as I recall. That Microsoft execution time may be longer than in other companies, and that in the end the innovation has become a “dead ringer”, this is not a scoop. So much for the Me Also.

Andy is also missing the final point: Microsoft flawed execution will make it to every corporate America’s desktop. And that is brilliance. Not on technological innovation, but on human behaviour understanding. Lesson to be learned for a marketing professional?

Indeed, if imitation is the highest form of flattery, many out there will be thanking Andy for bashing Microsoft without constructive arguments. Maybe after all is it easier and more comfortable to “join the crowd”… So much for the Me Copy.

Technorati Tags: XMPP, SIP, VoIP, Presence, Antecipate

"Battelling" for privacy

2006-06-21T16:13:00.000+02:00

Even if he denies it, John Battelle is discussing growing privacy concerns in this seemingly inocous post. But under the appearance lies an undisputable fact: privacy protection, be it written in laws or not, is at risk because of search.

Search provides a framework for thinking not only about mail (what is it about Gmail that makes it really unique? It's searchable…), but for our entire clickstream, which is fast becoming an asset.

What makes something private, beyond property, is the possibility to decide how that thing is exposed. As soon as there is exposure, privacy is breached. The first time you take your brand new car out of the garage, you make it public, and you loose part of your privacy. A letter is private when protected by the ephemeral barrier of the envelope, as it was yesterday by the seal maintaining the parchment roll. But what would we say about privacy, when the mailbox becomes searchable? Surely that is does not exist anymore.

What differentiate today's practices about personal data is the daily recording of growing quantity of "identifiable" information on centralized servers. The reasons are multiple. Simply put greed to access and monetize this information is a strong driver behind this trend. No doubt, recording of private information has existed for immemorial times. True, until recently it has been rather difficult to link together the different islands where that information was residing. Looking at what difficulties lies in reconstructing one's genealogy gives a good example of how "identified" information could be difficult to trace. But in the context of the web, these obstacles are vanishing. By looking at how people willingly release more "identified" private information everyday, this will become easier and easier.

One in ten internet users have registered at a social network, for example, and one in five have visited one. The reason for this shift is simple: innovative companies have figured out how to deliver great services (and make money) by divining clickstream patterns, be it a underlying divination, like PageRank, or a more direct one, such as AdWords or Amazon's recommendation system.

Needless to say, I believe this a result of abdicating any critical analysis of the associated risks. Adhering to a "social network" boost one's image by widening its exposure, and therefore by automatically decreasing one's privacy. Obviously, there is no "social networking" without releasing of a slice of personal "identified" information. Where would be the salt of life without gossip… And what is today's first mean of gaining exposure? Simply making sure this information appears on the top lines of search results… This is the first breach of privacy.

Behavioural experts will explain why the need for "exhibitionism" is common amongst humans, which makes me believe we are only at the beginning of the "social networking" adoption curve. The same experts will describe that the next step is to use distinctive signs and symbols. This is where the "innovative companies" come in to deliver "great services". Looking at it, how different is it to wear a tee-shirt with some well know brand, or to have it appear on your own "private" page. You don't get a dime out of it, the "social network" host does. This is the second breach of privacy. Obviously the "personalized" targeted add on your "private" page has been using your "identified" information…

More importantly, this seemingly disparate information, residing in the various service providers servers, can now be reconciled. Search can make these many data islands look like a wide open territory. The next frontier…
The privacy laws "fathers" have probably been blinded by technology experts in their laudable attempts at protecting this part of our identity. They where certainly told without a common database "key" personal information could not be correlated. Nowadays, with the growing power and refinement of the search engines, a common database "key" is not needed anymore, you only need a reference to an identity handle somewhere in a web page. The associated data does not need to be structured anymore. Search is slowly but surely circumventing all established privacy laws, with their outdated reference to unique keys.

Regaining control of our identity information and privacy starts by requiring that each of those "innovative companies" provides a "delete my information" button on the account management page of their services… It also requires that data held in their store be completely anonymized by using opaque indirect references. At least, if the data itself is not wiped out when I require it, it would only become part of the greater statistical whole. This is better than being "exposed" in public...

Technorati Tags: Identity, Digital privacy, Digital reputation, Digital identity, Antecipate

Weaving an identity society

2006-06-17T13:12:00.000+02:00

…Society must evolve to become an integrated yet privacy-enabled medium for people's diverse expressions of identity…

When I commented on Luke Razzell’s blog I wasn’t really expecting more than voicing an opinion on the growing Microsoft influence in the identity and privacy space. Luke hinted at the paper he had been co-authoring with John Madelin of BT to address some of the biased “laws” set by Kim Cameron and “set out a a more comprehensive vision of an Identity Web”.

Since then Luke’s announcement has become a reality, and taken the form of an open discussion wiki. The Web is becoming a more human-friendly and semantically-rich space, where people will be able to negotiate control of online information sharing. An “Identity Age” is dawning. The Identity Society wiki is aimed at discussing the nature of the associated challenges in depth:

Lead with thesis,
Avoid polemics,
Be accessible to a broad range of stakeholders,
Drill down from broad philosophical context to specific user requirements and business cases

For those wondering, this is what kept me away from blogging the past week…

Technorati Tags: Identity, Digital identity, Trust, Antecipate

Lesson to be learned ?

2006-06-09T13:57:00.000+02:00

Phil Zimmermann quietly released a reference application of his new cryptographic protocol ZRTP aimed at bringing privacy to VoIP conversations.

Zfone lets you whisper in someone’s ear, even if their ear is a thousand miles away. I think it’s better than the other approaches to secure VoIP, because it achieves security without reliance on a PKI, key certification, trust models, certificate authorities, or key management complexity that bedevils the email encryption world. It performs its key agreements and key management in a purely peer-to-peer manner over the RTP packet stream.

Beyond the point of certification authorities’ less than adequate certification procedures, it is rare when a user care to manage a secure list of accountable authorities in their clients. Today use of asymmetric cryptography in conjunction with PKI or trust models implies many risks and inconveniences, part of which is rooted in the necessity to securely managing private keys.

Zimmerman assumes that trust needs to be continuously renewed and updated between two parties in a conversation. Hence the ephemeral and point to point nature of his secure application. By decreasing the need for long term storage of sensible key material, it increases the overall security of the conversation. At the same time, I believe this is only solving part of the issue, as Bruce Schneier points out

No amount of IP telephony encryption can prevent a Trojan or worm on your computer — or just a hacker who managed to get access to your machine — from eavesdropping on your phone calls, just as no amount of SSL or e-mail encryption can prevent a Trojan on your computer from eavesdropping — or even modifying — your data.
So, as always, it boils down to this: We need secure computers and secure operating systems even more than we need secure transmission.

This is putting in better words than mine the objection I have to extend the JEP-0116 Encrypted sessions beyond online conversations. Will the XMPP community learn the lesson from these experts’ experience?

Technorati Tags: XMPP, Jabber, Security, Trust, Antecipate