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 have the great pleasure to announce Pretzel -- a Jabber server written in Python on the Twisted framework.

The two main authors are Ralph Meijer, well known as a long time member of the Jabber community, and Andy Smith, hacker extraordinaire.

For now, Andy checked in some experimental code hosted on Google's new code repository. Check it out at http://code.google.com/p/pretzel/. We're looking for other people to join in -- one of the reasons we started the project was because it seemed there were a lot of people looking for the same thing. It is available under the MIT license to make it potentially usable by the broadest number of people, as well as being under the same license as Twisted.

Please join us on the pretzel-dev list and we'll get the discussion going. 

What's on the roadmap? Well, this is a very early release -- more of a proof of concept. We hope to enable the quick and easy implementation of various JEPs, making it fun and simple to add all sorts of powerful features to the server and clients, truly showing how Jabber can go way beyond "just" instant messaging.

I'm now officially a member of the Jabber Software Foundation, according to the member meeting minutes.

For one of my first acts, I'll be at EuroOSCON's Dot Org Day (some info posted on the DrupalCon website -- if you are an open source project with presence in Europe, please attend!) helping RalphM and stpeter man the booth there.

That was one of the reasons I wanted to be "official" -- I've already unofficially been promoting/evangelizing Jabber, but now I can say that I'm a member of the JSF.

I hope to get more involved as a member, working on everything from web presence, conference attendance, and general promotion of Jabber-the-community and XMPP-the-protocol.

Help keep our instant messaging and real time protocols open, free, and standards based -- Jabber is for people :P 

I had lunch the other day with Aaron Gladders from 2Paths. He bumped into me when we were doing a final walkthrough of our new 1 Alexander offices, and recognized me from the picture here on my blog.

2Paths is a company filled with biologists turned programmers. They started out as a PHP shop, but since they provide full ongoing 24/7 support, hosting, and ongoing maintenance to most of their customers, they found that straight PHP code had a tendency to get very spaghetti-like. They switched to doing Java development and have been building expertise. Aaron confidently says that 2Paths is likely the best lightweight Java web application developer in Vancouver.

In fact, Aaron says they started to look at Ruby on Rails as it began to gain hype -- perhaps they would use it for prototyping. But they weren't happy with some aspects of it, although in favour of many of its lightweight aspects. So, they looked around for a Rails-like framework for Java. Ultimately, they rejected existing solutions for a number of architectural reasons and ended up creating their own. I'll leave it up to 2Paths to talk about its cool factor -- they'll be open sourcing it and releasing it to the world sometime real soon now (there might be a presentation at BarCamp Vancouver about it).

Scott Kveton announced the OpenID Code Bounty at OSCON today:

Integrate OpenID into your open source project and we’ll give $5,000 to your project.

We’ve seen OpenID really start to gain some momentum over the past couple of months and this Bounty program is really the exclamation point on that. There is a great list of sponsors for the program that includes people, organizations and businesses focused on building a simple, light-weight and decentralized user-centric identity platform around OpenID. Working with all of these people over the last couple of weeks has proven to me that convergence is really happening around OpenID.

I wasn't really a fan of the "original" OpenID spec. That is, it worked great, but only solved single sign-on. Then the Simple Registration Protocol, or SRP, got kludged in. This supports only 9 -- and exactly 9 -- attributes, and is not extensible. So, colour me firmly in the SXIP camp at this point.

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.