B. Mann Consulting

It doesn't seem that long ago, but the first Barcamp Amsterdam was way back in October 2005, where RalphM and I first schemed about Jabber World Domination. But in reality, a lot of time has passed -- Jabber is now called XMPP, there have been many more Barcamps outside of the US (yes, Amsterdam was first! picture from Ton's Flickr pictures), and we've got a ton of interesting identity and social software standards / formats / tools to start integrating.

Ralph did a workshop on Federated Social Networks at the beginning of December, which I unfortunately wasn't able to attend on short notice. Now Ralph has set the date for a follow up event to be held along with Barcamp Amsterdam III on March 1st and 2nd.

I will, unfortunately, once again be missing the event, since Drupalcon Boston 2008 will be happening at the same time. I'm hoping that some co-conspirators on a couple of projects will be able to attend (I'm looking at you and you).

I suspect the technology stack that will be discussed includes DiSo, OpenID, OpenID Attribute Exchange, and OAuth, so anyone interested in those items and how they relate to social networks should plan to attend. Note: although I have a reputation as a handwaver supreme, this will most likely be a down and dirty technology, specs, and implementation discussion at its core, so pack your developers and throw them into the capable hands of RalphM.

Les' comment was too good to languish in the comments. Content management systems and blogs are now clearly at the "easy to self host level". How long will it take to be able to easily do the same thing with a Jabber server?

In the light of ongoing PHP wrangling, PHP is also likely not the best language to be writing that server in.

What I think would be a hot "Twitter killer" (successor?) would be something self-hosted like WordPress or Drupal. I've been idly thinking about this since I first saw the site, so my ears perk up when I see discussion like this :)

I think XMPP would be excellent for communication for node-to-node and user-to-node. The user-to-user case works for a private IM back channel, but even there it might help to have a web-based Jabber client and maybe a custom XMPP server with an archival plugin tapping in.

Another thing I've been wondering is what limitations XMPP might introduce in deployment cost in a cheap PHP hosting world where WordPress, etal thrive? How hard is it to run your own XMPP server, or is it really necessary? (I'm spoiled because I've either always had root on my own dedicated / virtual server, or shared a server that had a Jabber server running.)

Along with XMPP, though, I think a few other federation options might be handy. Optionally CC'ing to an account on Twitter / Jaiku / iStalker / etc itself via the API to keep looped into an existing community - dirty, but handy. Also, polling RSS / Atom / JSON feeds to "pull" updates for a friend subscribed on the self-hosted node who's not in the XMPP loop.

In any case, I think XMPP is an excellent foundation for a network of self-hosted Twitter-esque nodes. I'm just wondering what else needs to be layered on and how.

 Now go over and subscribe to the rest of Les' stuff -- you probably know him as decafbad.

So, both Dave and Robert Scoble raked me over the coals for daring to say that a popular service with lots of users could be done differently. I had some good back and forth comments in Scoble's comment thread, re-posted below.

• I don't plan on building a "Twitter killer" using Jabber
• I don't think Twitter should go away...just that they might want to look at using Jabber directly as their core, which has many open benefits not the least of which is an automatic federation model
• I don't claim that the entire Twitter community could be duplicated: yes, I understand "it's the users, stupid!"...I can still wish for technological improvements

From my comment on Robert's post: 

I’d love to see a Jabber-to-Twitter API that means all the rest of us outside the walls of Twitter could interoperate, peer, and all that good stuff.

Building it around one company, no matter how many users it has, doesn’t seem like a particularly good idea.

Facebook implemented SMS notifications (”just like Twitter”) and has a TON of users. If we had a standard like Jabber in the middle, people could have joe@facebook.com accounts and jane@twitter.com accounts. And it would all just work

A note on Jabber/XMPP: XMPP is an open, IETF standard that has been used to implement a lot of IM-like functionality in the past. It also happens to be a protocol that’s great for passing around any sort of data where real time or publish and subscribe models make sense.

It’s all about the users: so make it so that ALL the users can talk to each other in a real federation model (which works today with Jabber), rather than being locked in Twitter’s trunk.

Robert's response:

Boris: now joining Facebook and Twitter sounds like a great opportunity! Building a bridge between two islands adds value. Trying to replace the islands doesn’t interest me at all. Building a third island that connects the other two? Good too! I guess it’s all in the semantics.

He goes on to say that "Twitter is NOT IM or SMS" and that he uses mainly the web interface. So...I agree. It's *the* area where Twitter has been innovating. A perfect thing to build on top of an open standard and add value.

Also left as a parting word in comments:

To me, XMPP is a real time version of RSS. That's the very shortest description I can make that also highlights the power and potential I think the protocol/standard itself has. 

OK, I finally lost it when I read Dave Winer's post re: Twitter premium:

Jason Calacanis is known for stimulating interesting discussion. Today is no different.  

He says he'd pay $100 a year for a Twitter that was always fast, almost always up, and had some additional features. 

I sent Jason a private email which I'll now repeat here. 

Just FYI, because of their API, you don't really need Ev and Biz to do that for you. A bunch of us could pool resources and set up a server of our own, and peer with Twitter's. If Twitter is down it would just queue up the messages, in the meantime, anyone who was on the premium system would see the messages immediately.  

 Look: forget Twitter. It has a bunch of users, that's about it. How to build twitter:

1. Install Jabber server
2. Install SMS gateway
3. Done

That's about it. And it has a publish and subscribe architecture built in, rather than all these crazy desktop apps that constantly poll the Twitter mothership. That's it. It's simple.

"Peering with Twitter". WTH. Built into the XMPP protocol. It's a standard. Works with lots of other things already. 

My only explanation for the Twitter craze is that North Americans are still enamored of anything that can do the tiniest bit of mobile integration. Yes, Twitter has managed to scale and spend many thousands of dollars paying for SMS gateways. Great! Maybe if they had built a front end on top of Jabber, they would have gotten there faster...

/me shakes head 

Update: Dave links back and explains that the number of users that have adopted Twitter is important. So...yes, I agree, I mean, I help build community sites for a living. So why are we talking about building an ecosystem around a company? Jabber would allow everyone who wants to build a real coral reef...one that doesn't rely on body of a company in the middle.

I'm in Stuttgart meeting with some clients. Lots of Drupal + Jabber integration talk, and luckily ralphm is here to bring along lots of Jabber expertise.

We've been talking a lot about geolocation notification over Jabber -- so users can indicate their location over Jabber. There are few (if any?) clients that support this today, so we'll probably support some short hand for testing purposes -- being able to type in geoloc:[lat],[lon].

So, I was looking at JEP-0080 (geoloc) and JEP-0112 (physloc). 112 is a plain text representation of physical location, and JEP 80 is the latitude / longitude. JEP 80 also has a plain text "description" field. So...why not collapse the two? physloc could replace the current JEP 80 "description" entry...every single entry is optional, so the text field in physloc can handle the current usage of the description field. It just seems wasteful to maintain two separate JEPs for what is essentially the same information.

As well, if a service already knows the physical location, it can send it along with the geoloc -- you can't derive the physical location from the geolocation, so in the current case, you would have to send two messages.

FOSDEM 2006 is over. The picture at left was taken by Dries Buytaert, showcasing the fact that this was my first appearance at an event being associated with Jabber. I'd put "officially" somewhere in that last sentence, but I'm not a member of the Jabber Software Foundation (JSF)*, so it's just my name on a presentation. I had a lot of fun co-presenting with Ralph for the second time -- he knows all the technical nitty gritty, and I wave my hands and try and open people's minds as to the current and future potential of XMPP.

Lots of people had heard about Jabber, and I think mine and Ralph's intro presentation on the first day helped hilight the point that I have been trying to make for a while now: that it's time for people to pick up the IETF-blessed XMPP standard and use it for real-time uses other than IM.

The picture at right is from my poking my head into the Jabber developer room on the second day -- every seat was taken and it was standing room only. Ralph by all accounts kept the room quite full, being stuck doing all the presentations as other presenters hadn't been able to make it. The Virtual Presence session (see the LLuna project for more info) became a step more virtual because the presenter wasn't in the room, but that itself became a great example of uses of the technology.

Some quick notes for an upcoming interview.

Benefits

• free voice calls between Skype users
• easy multi-person conferencing (up to 50, depending on bandwidth)
• multi-platform -- works on Windows, Mac, and Linux
• first IM client for many users who use voice feature first
• easy file sharing
• can have "real" phone numbers in many locations
• can also use video (various solutions, Windows only for now)
• Skype on your phone -- Microsoft PocketPC has a Skype client, EQO is new and works on Symbian Series 60 and other Java capable phones (client currently requires Windows on desktop)

Disclaimer: EQO is a local Vancouver company that I've met with, and my company Bryght powers their online community forums. They're also the only mobile app other than ShoZu that made my jaw drop (well, until I found out about the desktop client requirement...boo!).

Drawbacks

• have to have Skype to communicate (or pay for SkypeOut)
• built on a closed network, closed protocols (as opposed to open standards like SIP or JINGLE)
• computers on open networks might be used as a SuperNode, consuming lots of bandwidth
• Skype (now bought by Ebay) is the only provider of the service

Other forward looking options include click-to-buy or click-to-access solutions -- use your Skype ID and the client to pay for online goods and services, including restricted access to online content -- enter your Skype ID into a web form, get messaged with a special code, complete a transaction, receive an access code -- voila! instant online access. Note: this is of course possible with any IM service or even SMS, and Jabber is doing this today. In many ways, Skype is JAIS -- Just Another Identity Store -- that happens to have VoIP/IM/etc. built on top of it as an application.

hyperstruct left a comment announcing the developer preview release of this Firefox 1.5 plugin. It enables "real time social browsing" with an integrated Jabber IM client. Every URL creates a separate chatroom, so you can IM to other people that are viewing the same page as you.

I haven't tried it out yet, since I haven't upgraded to Firefox 1.5 yet. Soon! 

Via Dave Winer, I found this post by Mike Arrington talking about the AllPeers Firefox extension:

AllPeers is a simple, persistent buddy list in the browser. Initially, interaction with those buddies will be limited to discovering and sharing files - If you choose to, you can share any file on your network with one or more of your friends. They will be able to see what files you choose to share (even getting an RSS feed of new files you include), and with a single click download it to their own hard drive.

AllPeers is private, P2P file sharing using BitTorrent to do the transfer, implemented as a Firefox extension. It involves buddylists as well, so I left a comment on Mike's site that they should use XMPP to power the buddylist. Buddylists and IM capabilities in the browser (which are proxies for identity and peer-to-peer communication, respectively) are destined to have some sort of representation directly in the browser. This might be something for Flock to think about.

As Ralph Meijer puts it, I am still delinquent in publishing the notes I took after BarCamp Amsterdam:

I suppose the plan for World Domination™ will remain a secret until Boris Mann publishes the result of the notes he took at BarCamp Amsterdam. The event was totally awesome. Thanks all!

I'm *still* carrying the notes around with me -- I had the great good fortune to spend a lot of time with Ralph and Edwinn and suck all the Jabber aka XMPP knowledge I could out of them that I could. I've been following the growth of Jabber/XMPP for years, and here are some of the concepts and happenings which I think are going to blow it wide open in 2006:

• A major Internet entity commits to natively using the XMPP protocol for a new IM network: Google did this with the release of GoogleTalk; their recent deal with IM makes me think that Google - AOL - Apple iChat interoperability could happen in 2006. At any point, Google could also turn on gateway services to MSN and Yahoo as well.
• Consumer multi-network IM gets funding: Meebo got WAAAAY too much money. It's a simple, simple service, and there is no unique technology or IP. BUT...why are so many people using it? Because being able to talk to all your friends, no matter which network, is the killer app. And while the Mac has one of the best multi-network clients ever in Adium, on Windows it's just a pain. Oh, and web apps that you can get to from anywhere -- especially for a communication app like IM -- are infinitely better than desktop installs.
• XMPP isn't just about IM anymore: there have always been really cool examples floating around in the Jabber community (e.g. Google Maps + Jabber, including a *very* cool way to login by having the server message you a login phrase), but the really big news is JINGLE, including the immediate release of an audio transport, with Asterisk integration almost immediately and video probably not far behind.
• Increasing open source activity: eJabberd is one of the best XMPP servers period. For Java-heads, there is Jive Software's Wildfire, now available under a dual license. Jive Software also released a Flash Jabber API called XIFF, meaning you could build your own version of GTalkr (disclaimer: I know Wes and Dudley, the masterminds behind GTalkr...it's not that easy, and right this minute they're installing killer features to blow your mind :P). Now all we need to make Jabber really accessible for developers is a great server written in one of the "P" languages -- PHP, Python, or Perl. Since the Python Twisted networking stack has Jabber support in the Twisted Words component, and Python makes for great daemon-izable apps, it's probably the best choice.
• The push for realtime: this goes hand in hand with the last point. The super secret part of XMPP is that it's not about IM at all...it's a generalized XML message passing protocol optimized for real-time. Every ounce of effort to get faster polling of RSS is wasted...it's an asynchronous poll model -- XMPP is the step beyond. I suggested that Plazes throw away it's proprietary protocol and use XMPP directly, preferably using the User Geolocation JEP that has already been defined for exactly such uses. Anything else you want to pass around in real time that can be represented in XML? Like real-time ATOM? Yep, the possibilities are endless.

What are my next steps with XMPP? Well, I'm getting very interested in what a combination of a Jabber server plus identity store might be able to do. Parceltongue is a placeholder for potentially writing such a server in Python (why another server? well, part of that is in the secret notes...let's just say that Jabberd 1.x and Jabber 2.x are both needed if you want to run a complete set of services, plus the aforementioned desire for a "P" language to run a Jabber server with).