Come on in!

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

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

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

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

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

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

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

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

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…

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