about

who
what
where
when
why
how
comments

feeds

ATOM

RSS

categories

identity
jabber
language
literature
music
personal
philosophy
politics
public domain
society
technology

archive

current
2007-04
2007-03
2007-02
2007-01
2006-12
2006-11
2006-10
2006-09
2006-08
2006-07
2006-06
2006-05
2006-04
2006-03
2006-02
2006-01
2005-12
2005-11
2005-10
2005-09
2005-08
2005-07
2005-06
2005-05
2005-04
2005-03
2005-02
2005-01
2004-12
2004-11
2004-10
2004-09
2004-08
2004-07
2004-06
2004-05
2004-04
2004-03
2004-02
2004-01
2003-12
2003-11
2003-10
2003-09
2003-08
2003-07
2003-06
2003-05
2003-04
2003-03
2003-02
2003-01
2002-12
2002-11
2002-10
2002-09
2002-08
2002-07
2002-06
2002-05
2002-04
2002-03
2002-02
2002-01
2001-12
2001-11
2001-10
2001-09

2004-08-31

Dereferencing?

Further thoughts on the state of the bulb.

Feedback continues to pour in regarding my previous posts on the state of the Jabber community. Various good discussion list threads and one-to-one conversations have led me to rethink some of my assumptions about problems and solutions. Since step one is to correctly diagnose the problem, we need to get that right before we can figure out the best course of action. Here is a short list of what I see as deficiencies in the Jabber community:

1. the main free servers (jabberd 1.4.3 and jabberd2) are protocol-incomplete, hard to code for, and hard to administer
2. we have way too many incomplete clients, very few semi-complete clients, and no protocol-complete clients
3. too many Jabber clients have horrible user interfaces
4. we don't have good, high-level libraries for the main computing platforms
5. we have too many one-person projects
6. we don't have good documentation (user guides, admin guides, developer guides, code comments)

It's not clear that creating one reference implementation (or, realistically, one server, one client, and one library) is the way to solve these problems. Yes, we have too many clients, but some of them are close to protocol-compliant and it might be better to encourage developers to make them fully compliant rather than trying to write one cross-platform client (whose user interface would likely be sub-optimal on several platforms). The same goes for servers: it might be better to expend the effort to push jabberd2 over the top rather than to write a new server. One way to encourage this would be for the Jabber Software Foundation to finally develop a protocol compliance testing process (initially based on the protocol suites defined in JEPs 73 and 117). A contributing factor here may be that, although the JSF cares about protocol compliance, most end users and system admins don't. Do people really care if their clients and servers use SASL/TLS for XML streams? Seemingly not.

Naturally, protocol compliance does not address ease of use. The fact that various Jabber clients are not user-friendly, or that various Jabber servers are hard to install and administer, goes beyond protocol compliance. Although JSF members may have opinions regarding usability, the JSF may not be the best body to test for usability. On the server side, the problem is often one of packaging (notoriously hard) and documentation (notoriously boring). On the client side, the problem is that usability is more art than science, and many (most?) developers are not attuned to usability. Here again, I'm no longer convinced that a reference implementation would save the day.

As to libraries, one comment that Peter Millard and Ryan Eatmon heard repeatedly at OSCON 2004 was that it would be nice to have a great Python library. But there already exist several good Python libraries, some of which need to be extended to support more high-level functionality. One of the challenges with regard to libraries is that everyone has their preferred language: some folks want to code in Perl, others in Python, others in Java, C, C++, or whatever. Another challenge is that developing applications for particular platforms simply cries out for platform-specific libraries; for example, Macintosh developers these days most likely want a Cocoa library written in Objective-C, not a Python library. This might be an area in which a company like Apple could make a strong contribution to the Jabber community.

The plethora of one-person projects is a tougher nut to crack. Personally I'm not opposed to one-person projects per se; the problem arises when the project is one that many people depend on and the one developer loses interest. The result is stagnation. One thing that would help is well-documented code, but most coders don't take time to comment their code in depth, and your typical tech writer doesn't grok the code well enough to comment the code or write helpful code-level documentation. I'm not yet sure how to address this, but I'm sure that other open-source projects have run into the same issues, so there must be some best practices in this area. Further research required.

As to documentation, I don't think the existing user guides and admin guides are that bad (perhaps I'm biased, since I wrote many of them). It would be great if the leading Jabber clients included inline help (I've promised Peter Millard that I would do this for Exodus, but I haven't gotten to it yet -- my bad!). Some components contain only skimpy READMEs, which are acceptable for fairly geeky sysadmins but aren't all that friendly (here again, the answer may be packaging -- but who wants to do packaging?).

One of my correspondents pointed out that the impetus for all this may been my recent switch to OS X, for which there is no good Jabber client. That may be so. But I think the issues go beyond my personal frustration with Jabbering on the PowerBook. Feature incompleteness, poor documentation, unfriendly interfaces, and bad packaging are problems endemic to the open-source community, and perhaps even to code in general (though commercial software developers often do a better job on some of these because they can pay people to work on things that aren't all that interesting). I'm not yet sure how we can address these issues in the Jabber community and I'm less convinced than I was that reference implementations are the answer, but I do know that we need to find a way to address them if we are to thrive.

May the conversation continue!

Posted on 2004-08-31 at 21:51. File under jabber.

~ link ~

Pythonic II

Jabber and Python again.

In response to my previous post about Jabber and Python, Jacek Konieczny (author of the pyxmpp library among much other code) informed me that Python includes IDN support in the standard Python 2.3 libraries. He's also written his own SASL support in pyxmpp, and uses the M2Crypto library for TLS. Thanks for the good news, Jacek!

Posted on 2004-08-31 at 09:06. File under jabber.

~ link ~

2004-08-26

Improving Knowledge

The habit of scientific thinking.

Carl Malamud's report on restructuring the adminstrative functions of the IETF kindly recognizes the contribution of the JSF to IETF meetings:

Assistance from members of the community is an important part of staging an IETF meeting. In addition to formal secretariat activities, at least three teams of volunteers have been active recently....

A team of volunteers organized by xmpp.org manages a series of XMPP servers which are used for general commentary by participants, creation of informal transcriptions which are archived, and for a variety of personal productivity enhancements.

More significantly, it brings together some background information about standards organizations such as the Institute of Radio Engineers and, even earlier, the Royal Society. Regarding the latter, Malamud links to an essay entitled On the Advisableness of Improving Natural Knowledge by Thomas Huxley, which ends as follows:

The improver of natural knowledge absolutely refuses to acknowledge authority, as such. For him, scepticism is the highest of duties; blind faith the one unpardonable sin. And it cannot be otherwise, for every great advance in natural knowledge has involved the absolute rejection of authority, the cherishing of the keenest scepticism, the annihilation of the spirit of blind faith; and the most ardent votary of science holds his firmest convictions, not because the men he most venerates hold them; not because their verity is testified by portents and wonders; but because his experience teaches him that whenever he chooses to bring these convictions into contact with their primary source, Nature -- whenever he thinks fit to test them by appealing to experiment and to observation -- Nature will confirm them. The man of science has learned to believe in justification, not by faith, but by verification.

Thus, without for a moment pretending to despise the practical results of the improvement of natural knowledge, and its beneficial influence on material civilization, it must, I think, be admitted that the great ideas, some of which I have indicated, and the ethical spirit which I have endeavoured to sketch, in the few moments which remained at my disposal, constitute the real and permanent significance of natural knowledge.

If these ideas be destined, as I believe they are, to be more and more firmly established as the world grows older; if that spirit be fated, as I believe it is, to extend itself into all departments of human thought, and to become co-extensive with the range of knowledge; if, as our race approaches its maturity, it discovers, as I believe it will, that there is but one kind of knowledge and but one method of acquiring it; then we, who are still children, may justly feel it our highest duty to recognise the advisableness of improving natural knowledge, and so to aid ourselves and our successors in their course towards the noble goal which lies before mankind.

Well said!

Posted on 2004-08-26 at 16:53. File under society.

~ link ~

Pythonic

SASL and TLS and IDN, oh my!

Doing a little research on what might be needed in order to develop a Python reference implementation of XMPP and various XMPP extensions, I've come across M2Crypto (a crypto and SSL toolkit for Python) and TLS Lite (a Python library that implements SSL 3.0 and TLS 1.0). But I don't see any SASL or IDN implementations in Python yet, so it might be necessary to wrap C libraries like libgsasl or libidn (or to write native Python implementations). Hmm.

Posted on 2004-08-26 at 15:59. File under jabber.

~ link ~

Volity

Gaming over XMPP.

Not many people have heard of Volity yet. It's a platform (largely based on XMPP) for building and playing multiplayer games over the net. It seems that the Volity folks are trying to do file transfer over XMPP in some creative, er, non-standard ways. Why not use JEP-0096? We don't write these specs for fun, ya know. ;-)

Naturally, it could be that the Volity folks have some special requirements that aren't covered by JEP-0096 and its dependencies. But if so, I'd like to hear what they are so we can improve the JSF specs before they go final.

Posted on 2004-08-26 at 15:37. File under jabber.

~ link ~

Pubsubbing

More about Atom over XMPP.

Yesterday Bob Wyman announced PubSub SideBar over on the Atom-syntax discussion list and invited folks to sample the service in order to "demonstrate the benefits of transferring Atom over XMPP". Good work! Bob also has provided some great feedback on the Atom over XMPP draft, which Joe and I will probably rev next week. Stay tuned!

Posted on 2004-08-26 at 15:29. File under jabber.

~ link ~

2004-08-25

Liberty and Peace

Asking some tough questions.

My friend Perry Metzger asks some questions about liberty, libertarians, and the war in Iraq. I don't have the answers but the questions are eminently worth asking.

Posted on 2004-08-25 at 16:35. File under politics.

~ link ~

Proofing II

PGDP and Jabber.

So I just joined Project Gutenberg's Distributed Proofreaders project (a.k.a. PGDP) and it turns out that they use Jabber for a lot of their communications. In the main PGDP chatroom (pgdp@conference.jabber.org), pourlean (one of the project admins) reports that using Jabber has really helped their productivity. Perhaps a case study is in order...

Posted on 2004-08-25 at 16:33. File under jabber.

~ link ~

Proofing

Putting my editing skills to work.

Today's Slashdot story finally spurred me to join the Distributed Proofreaders project. Not that I have lots of time for it, but I hope to contribute in my spare moments (especially on books that have a bit of Latin and Greek in them). It's a worthy cause.

Posted on 2004-08-25 at 15:32. File under personal.

~ link ~

Pubsub Goes Atomic

Getting fed in a hurry, the Atom way.

Last week, Joe Hildebrand and I submitted an Internet-Draft for sending Atom notifications over XMPP pubsub. So far the response has been quite positive (though that last link should also mention pgmillard, author of the pubsub spec). It's early yet for Atom over pubsub because Atom 1.0 is evolving rapidly and we're working to gain more pubsub implementation experience, but the idea seems to have promise. :-)

Posted on 2004-08-25 at 13:36. File under jabber.

~ link ~

2004-08-23

The Cut

Prunage complete.

OK, I've finished my roster deletions. I'm now down to about 200 contacts, but even still I had to downgrade to Nitro 0.5 in order for it to work. Maybe more memory will help with Nitro 0.6+. Otherwise I'll have to learn Objective-C (which I may have to do anyway to turn off these annoying message notification bells and bouncing tray icons...). ;-)

My roster has not been this small for years. I guess I won't be an example of huge rosters anymore, eh?

Posted on 2004-08-23 at 13:28. File under jabber.

~ link ~

Prunage

Roster cleaning in progress.

I'm famous in the Jabber community for having a huge roster (Jabber lingo for a contact list). At one point I had over 1300 people in my roster. Since then I've pared it way back and I'm now down to 350 or so. However, I'm going to prune it still further because the existing Jabber clients for OS X don't handle my roster very well (some hang, some engage in continuous redraws), and the only one that handles my roster (Adium) is well-nigh unusable since its XHTML bug prevents some people I need to chat with from reading the messages I send them. So I'm going to get even more ruthless and delete more people from my roster. Don't take it personally, OK? ;-)

Posted on 2004-08-23 at 11:21. File under jabber.

~ link ~

Dive Into Specs

Or, why the last three years of my life may be justified after all.

Mark Pilgrim explains why specs matter (thanks to hildjj for the link).

Posted on 2004-08-23 at 09:56. File under jabber.

~ link ~

SIP at Risk

Proprietary SIP and competing protocols.

A few months back I was a speaker at the SIP Summit in Chicago. One result seems to be that I am now subscribed to von magazine, which this month contains a fascinating article on the emergence of proprietary flavors of SIP. It turns out that SIP is so "powerful" that vendors are happily adding their own proprietary extensions, leading to a lack of interoperability. (We've already seen the same thing with SIMPLE as well, since Microsoft's version of SIMPLE won't interoperate with IBM's). What good are standards if they don't result in interoperability? In any case, the rise of proprietary SIP is leading to the development of open, simpler alternatives. The front-runner seems to be IAX, which is the protocol behind Asterisk, an open-source PBX software suite. The IAX wiki says:

• IAX is not the result of a standards group, rather a collaborative, community based effort (sound familiar?)
• IAX uses a single UDP port, IAX uses 5036 and IAX2 uses 4569, and thus works well in NAT environments

Intriguing. The IAX vs. SIP page provides a good overview.

Posted on 2004-08-23 at 08:51. File under jabber.

~ link ~

2004-08-20

IMVU

Avatar city.

I'm chatting right now with Eric Ries of IMVU, a company that provides avatar environments for instant messaging. Longtime readers of this weblog know that I'm pretty much a vi and CLI kind of guy, but even I am impressed by IMVU.

I mean, you can chat like this:

Or you can chat like this:

Now, I would still choose the textual interface since I'm a primitivist, but I can see lots of people going for the avatar environment. (About which: why are those avatar chicks always such babes?)

Another cool thing is that Eric tells me that IMVU has developed "a censorship-free micropayment economy for virtual items". Whoa, parse that! Essentially, IMVU has created the tools that independent artists use to create these avatars and scenes. Artists create the images and add them to IMVU's catalog. Then end users buy the images from IMVU, who takes a cut and sends the rest of the money on to the artists. What a cool model!

Eric says this avatar integration is 50 lines of Python and that he's going to make it available under GPL or some other OSI license so that any Jabber client could add IMVU support. Sweetness.

Posted on 2004-08-20 at 15:29. File under jabber.

~ link ~

2004-08-18

Refs

From JSF to IETF.

This morning I started working on an Internet-Draft defining how to send Atom notifications using the XMPP pubsub extension as the transport mechanism. I quickly realized that in referring to a JEP in an I-D, it sure would be helpful to have pre-defined XML reference snippets that conform to the XML format defined in RFC 2629. So I coded up some XSLT to generate the reference files and a shell script + cron job to keep the tar and zip files up to date. It's all located at http://www.jabber.org/jeps/refs/ and now listed as one of the citation libraries at the xml2rfc website. Enjoy!

Posted on 2004-08-18 at 13:51. File under jabber.

~ link ~

2004-08-17

Numbers Once Again

The glacier keeps moving.

As promised, the various IMPP WG specifications have just been released as RFCs 3859, 3860, 3861, 3862, and 3863. Now we just need to get those IANA registrations done and the XMPP specs should be releasable as RFCs, too.

Posted on 2004-08-17 at 20:36. File under jabber.

~ link ~

2004-08-16

Queueing

More JEP management tools.

This evening I wrote some tools and interfaces to keep better track of JEPs that are in line for consideration by the Jabber Council; the public face to these improvements is a Council queue web page. Hopefully something like this will enable the Council to set its priorities and enable developers to get a better idea of which protocols will be approved when. Feedback welcome as always.

Posted on 2004-08-16 at 22:07. File under jabber.

~ link ~

One Ring?

What it means to be a reference implementation.

I've gotten some heat about my posts on a thousand points of light and more light. For example, a Jabber friend of mine pointed me to a thread over at the Psi forums in which someone claimed that I am calling for "one client to rule them all". Far from it. What I'm calling for is the development of a reference implementation, which Wikipedia defines as "a software example of a standard for use in helping others implement their own versions of the standard". One reason for developing a reference implementation is to make it easier for others to develop their own implementations, which is why I think Python would be the best language in which to write the reference implementation (Python is relatively easy to learn, easy to read, easy to understand -- at least compared to, say, C++). A reference implementation of the Jabber/XMPP protocols won't necessarily be production-quality on the server side or especially slick on the client side -- it might be, but that's not the primary point. I still firmly believe in letting a hundred flowers bloom and the free marketplace of code. But we need to make it easier for developers to create implementations of protocols such as Ad-Hoc Commands, SOCKS5 Bytestreams, and the stringprep profiles defined in XMPP Core. It seems to me that reference implementations (server, client, and library) could go a long way toward making that a reality.

Posted on 2004-08-16 at 15:49. File under jabber.

~ link ~

XMPP URI

More IETF progress.

Last Friday I submitted draft-saintandre-xmpp-uri-04 to the IETF Secretariat. Barring unforeseen obstacles, I think this will be the version that I submit to the IESG (with an accompanying note that it has been reviewed by the XMPP WG, naturally).

Posted on 2004-08-16 at 15:20. File under jabber.

~ link ~

Numbers Redux

XMPP RFC update.

Herewith an update on the prospect of RFC numbers for the XMPP Internet-Drafts:

After some strategic pokage here and there, it seems that all of the authors for the following documents have signed off on the "Author's 48 Hours" modifications, which means they will soon emerge with RFC numbers:

• draft-ietf-impp-im-04
• draft-ietf-impp-pres-04
• draft-ietf-impp-cpim-msgfmt-08
• draft-ietf-impp-cpim-pidf-08

Because these are the only non-RFC documents on which the XMPP specs depend, yet another hurdle has been removed. (The dependency trees can get rather involved: XMPP Core is joined at the hip to XMPP IM, which has a normative reference to XMPP E2E, which has references to both PIDF and MSGFMT.)

The IANA still needs to complete its various bits of work related to the foregoing XMPP specs, which I would think will happen fairly soon since the IAB's IANA report says that XMPP Core and XMPP IM have been in the IANA queue longer than any other documents:

draft-ietf-xmpp-im 20040731 current status IANA since 20040225 ( 157 days)
draft-ietf-xmpp-core 20040731 current status IANA since 20040225 ( 157 days)

I've sent an email to the good people at the IANA asking them if there is anything they need from me to move forward with the registrations specified in the XMPP documents, and hope to hear back shortly. So we're getting closer.

Posted on 2004-08-16 at 15:07. File under jabber.

~ link ~

2004-08-12

A Pyrrhic Victory

Why crypto doesn't matter.

Sadly, this seems to be true: we have the right to use cryptographic technology, but we don't do so. Part of the problem is that it's too darn hard. How many normal people (non-geeks) have PGP keys and use them? Technology developers are duty-bound, I think, to make this stuff much easier. Dizzy wants to make this a priority in the Jabber community and I agree. There was a good presentation about this at one of the IETF plenary sessions, updating the information in RFC 2316. The bottom line is that some security technologies are in wide use (SSH, SSL) because they are relatively easy to use, but most are not. We can do better.

Posted on 2004-08-12 at 10:47. File under technology.

~ link ~

2004-08-11

More Light

Jabber follow-up.

Yesterday's entry about what's rotten in the Jabber community has elicited quite a bit of feedback so far. Julian Missig says that there's no such thing as a good cross-platform client. Someone poked me via Jabber to say that all my ideas were great except that Python is a horrible language and let's do all this in C++. Several folks volunteered to help with the Python work (which would probably start with a really good Python library). Others continue the theme and point out that unimplemented specs are useless (to be fair, the older core specs are fully implemented and have been since 1999, otherwise no one would be paying attention to Jabber at this point). So at least we have the juices flowing.

As to whether it's possible to build a good cross-platform client, I'm not yet qualified to say. I would say that the Mozilla folks have done it -- the fact that OS Xers use Safari and Mail instead of Firefox and Thunderbird doesn't imply anything about whether these Mozilla apps are objectively good on OS X, only whether they are popular (for that matter, they're not popular on Windows compared to IE and Outlook, either). The good people at OSAF are working towards something similar with Chandler, and are pouring resources into the Mac version of wxWidgets to make this happen. You can complain that Chandler is vaporware and that Mozilla is a fluke, but people are working on this stuff and even if good cross-platform clients are not a reality today, nothing says they are impossible (lord knows that in the Jabber world there are only a very few good single-platform clients out there, so the problem is not limited to the cross-platform arena). At Julian's blog, temas noted that part of the problem may be the plethora of multi-protocol IM clients; I agree in part (multi-protocol clients tend to settle for least-common-denominator functionality), but developer burnout and single-person projects may have more to do with it. All this is of course pure speculation, and we won't find out if it's possible to write a really good, single-purpose (Jabber-only), cross-platform Jabber client unless we try. I still hold out hope for Jabberzilla but it's a bit early to say for sure if that will succeed (though I plan to at least start helping with some docs and code on JZ soon).

As to a cross-platform server written in Python, here again opinions differ and the only way to tell if it's possible is to try. Immediately people were poking me about scalability (will it scale up to 10,000 simultaneous sessions?). But notice that scalability was not on my list of priorities. A really stable server would be good, but I don't see a strong need for a server that scales beyond 1,000 concurrent users. That won't help us on jabber.org (where of the 200,000+ registered users we usually have about 6,000 online at any one time), but most smaller companies, schools, non-profits, and ISPs (80% or 90% of the "market") would do just fine with a server that scales to 1,000 concurrent users. Larger organizations tend to have lots of money and therefore can talk to one of the commercial XMPP server vendors.

The other day, Mitchell Baker posted some thoughts on building open-source communities based on a BOF that happened at OSCON 2004 (Jabberites Peter Millard and Ryan Eatmon were there after presenting their tutorial, and chatting with them is what put a bug in my ear about all this). The Jabber community has long valued independence, so much so that we lack cohesion. Sure, we've got a great technology (it still blows my mind that Jer thought up the whole idea of streaming XML), but we're not really working together to build out the potential of our technological foundations. We changed the focus from code to specs at a certain point and now we lack the momentum we need as an open-source community (as distinct from a technology community). The Jabber pioneers were able to make so much progress in 1999 because they were a small, focused group that pursued separate projects (jabberd, Winjab, Gabber, Net::Jabber, etc.) but worked toward a common vision in a coordinated way. We can't duplicate that success now, but we can emulate it with appropriate changes for the "modern" Jabber context.

Perhaps one strong server group and multiple client groups will work better than a single client effort. I think that a single client is worth trying, and I think Python is the way to go for server, client, and library. Who would work on these inter-related projects? Lots of folks seem interested. Who would pay them? Perhaps we can aggressively seek donations, either through the JSF (if these are sponsored projects to build reference implementations) or independently, either from corporations or through grants. Would this Python initiative stifle innovation? I don't think so -- in fact, existing servers and clients would probably be spurred to greater heights by the competition. Would a stronger open-source community challenge the commercial XMPP vendors? You bet it would, but I think the focus is different and we need a vibrant open-source codebase to provide reference implementations and safeguard the openness of the protocols.

Naturally we can talk about this forever. The key is to get active. One research topic on the client side is wxPython (there are tutorials and howtos and getting started guides and cookbooks and wikis galore). For the server, we probably need to look more deeply into whether Twisted is the way to go. Perhaps the first step is to write a really good Python library: while there are several existing libraries, they are all pretty low-level, whereas I think we need to build something that encapsulates lots of functionality for developers and doesn't force people to build or grovel through various IQ namespaces (though it should allow developers to do their custom stuff, it support all the draft JEPs out of the box -- note that the list of Draft JEPs will be much bigger by the end of the year if I have anything to do with it). The goal should be to write a library that is worthy of inclusion in the Python Standard Library (see PEP 2), even if it takes a while to achieve that level of maturity and acceptance.

Posted on 2004-08-11 at 19:53. File under jabber.

~ link ~

2004-08-10

A Thousands Points of Light

The state of the bulb.

There is something rotten in the Jabber community.

There have now been over 300,000 downloads of the jabberd 1.4.x and jabber2 servers (not to mention other servers such as ejabberd and commercial offerings from various companies). The core Jabber protocols have been ratified by the IETF under the name XMPP. Word has it that big companies like Oracle and Sun have adopted Jabber technologies. The JSF continues to crank out XMPP extensions in its JEP series. There are Jabber libraries for Perl, Python, Ruby, Java, C, and many other languages. There are literally hundreds of Jabber clients. So why is something rotten?

As anyone who subscribes to the JADMIN mailing list can tell you, the existing server options all have issues, from difficulty of installation to lack of documentation to missing protocols to inability to run the existing gateways to non-Jabber IM services. As anyone who talks with Jabber users knows, there are hundreds of Jabber clients but almost all of them are close to useless. I chat with server admins and end users all the time, so I hear these complaints in abundance. I'm beginning to think that it's time to do something about it.

What's the solution? I see two critical pieces:

1. A modular, hackable, well-documented, cross-platform, easy-to-use, protocol-compliant server.
2. A modular, hackable, well-documented, cross-platform, easy-to-use, protocol-compliant client.

Let's go over those adjectives, shall we?

• Modular -- designed so that people can contribute to it without having to grok the entire codebase.
• Hackable -- written in a language that lots of developers understand and can productively code in.
• Well-documented -- including a complete architectural description, user/admin guide, and in-depth comments in the code (see hackability above).
• Cross-platform -- works on Linux/Unix, Windows, and Mac OS X.
• Easy-to-use -- no more difficult configuration or installation, good user interfaces, and lots of help files.
• Protocol-compliant -- wouldn't it be cool if you could actually make use of protocols like pubsub, XHTML, and file transfer?
• Server | Client -- Jabber is a client-server system, so we need both.

Why don't we have these two things right now? One big reason, as I've discussed recently with Peter Millard and Ryan Eatmon, is that the Jabber community contains a plethora of one-person projects. We have a thousand points of light, but they are so widely scattered that server admins and end users are still pretty much in the dark.

What do I propose? Although I am not known for my hacking skills, I've found that one language is more productive for me than any other: Python. A well-designed, well-documented Jabber server and client written in Python might just be the trick. (Yes, I appreciate all the work that has gone into jabberd 1.4 and jabberd2 on the server side, but C is simply not accessible for most developers; yes, Exodus and Psi and Jabberzilla and other clients have received attention over time, but most of them are one-person projects or written in languages that again are not as open or accessible.)

I've heard the objections before: Python is just a scripting language. A Python server wouldn't scale (real servers are written in C). The client-side widget sets for Python are clunky (we need native apps that are slick as hell).

I'm not so sure. For one, you'll notice that I didn't include scalability in the foregoing requirements. A server that scales from 1 to 1000 users is all that most small organizations really need. Bigger organizations can contract with one of the server vendors.

On the client side, people complain about things like Tkinter and wxWidgets. But wxWidgets is coming along and the folks at OSAF are using it (and improving it) for Chandler (here is a nice OS X screenshot from the Audacity application). Sure, the result might not be the client to please all people, and some developers would continue to write their own clients. But in general I think we could standardize on a common Jabber client for the major OSes.

So how do we do this? Do we add the "S" back into the JSF and start creating official software projects? Perhaps. I note that even a standards organization like the W3C writes software, as witness the Amaya browser. And groups such as the Apache Software Foundation are seriously productive. Perhaps we have strayed too far towards the protocol side of things. We have certainly strayed from what makes open-source projects successful in the long run (modular code, accessible languages, good user interfaces, strong documentation). But whether this happens inside or outside the JSF, it needs to happen. We can't continue to work this way, at least not if we expect Jabber technologies to succeed. World domination doesn't happen by accident.

As always, let the flames begin.

Posted on 2004-08-10 at 17:01. File under jabber.

~ link ~

xmpp.org

Website beginnings.

Today I finally put the XMPP schemas online and created some content for the xmpp.org website. It's fairly primitive at this point, but at least provides some information and no longer redirects to www.jabber.org. More work is required to make it a fully functional website.

Posted on 2004-08-10 at 14:34. File under jabber.

~ link ~

2004-08-09

Tools

Progress regarding mantra #2.

Today I finished some tools I've written to help me manage password requests for the jabber.org server. In the past these went directly to my email inbox, which was rather at odds with mantra #1 ("email must die"). Now each person's request parameters (jabber.org username, last login, and at least one friend in the user's contact list) go into a database thanks to a PHP script. Every hour, cron invokes a shell script that queries a remote database (to which only two or three people have access) for the person's roster, last login, and password as contained in the PostgreSQL database that houses user information for the jabber.org server. Then a Python script populates the local password lookup database, which I can manage through a PHP front end. It's a rather Rube-Golberg-ish solution right now, but it works and it saves me quite a bit of time. Plus, it will enable folks other than the three special people with production access to answer password requests.

Fewer specs, more code!

Posted on 2004-08-09 at 20:43. File under jabber.

~ link ~

Jabber @ IETF

Side channels and undernets.

The Jabber chatrooms that we run at ietf.xmpp.org and irtf.xmpp.org are always popular during IETF meetings. They seem to have two main uses:

1. Semi-official side channel during WG sessions. For example, during the second MARID session (which I scribed), people were listening in to the audio feeds and used the Jabber room as a way to ask questions, which were relayed IRL by someone in the meeting room (often by WG co-chair Marshall Rose, who was following the chatroom discussion while running the real meeting).

2. Utterly unofficial undernet during plenary sessions. The meeting room of choice is called "badattitude" and lives up to its name. The discussion here is freewheeling and irreverent -- something like Mystery Science Theater 3000 but with plenary speakers instead of bad movies as the objects of ridicule. It's this room that had Tim Bray worried about some of the forthcoming process changes within the IETF, but it's best not to read too much into such yammering -- I saw it mostly as a way to let off steam.

The highlight was when IETF chair Harald Alvestrand went up to the podium to give his talk before 1200 or so people during the second plenary session on Thursday night, since he joked that he was doing what seems to be the first order of business for all the speakers: minimizing the Jabber chat room! (BTW, I spotted an Exodus icon in his system tray -- go pgm!)

Posted on 2004-08-09 at 10:01. File under jabber.

~ link ~

Push

XMPP and the limits of the web.

Adam Bosworth, who just moved from BEA to Google, seems to be blogging again, most recently about the importance of simplicity. In a blog entry from last year (7/25/2003, but no permalink), he praised the web as easy to use and generally the right solution -- except that "there are two things it isn't particularly good at..."

• Offline Access. IE's attempt to make sites go on working offline is a joke. Offline requires a new paradigm.

• Push. If Information needs to flow to the user more or less as it occurs then the browser paradigm isn't always the best model, at least without help.

Methinks we have a great technology for push: XMPP. But offline access is another story.

Posted on 2004-08-09 at 09:28. File under jabber.

~ link ~

2004-08-08

The Organ Grinder and the Monkeys

On the futility of voting.

Thanks to a link from Russell Whitaker, I found an essay entitled A Thousand Dusty Codicils by George Monbiot, which contains the following sentences:

Only the people will hold the government to account. They have two means of doing so. The first is to throw it out of office at the next election. This works only when we are permitted to choose an alternative set of policies. But in almost every nation, a new contract has now been struck between the main political parties: they have chosen to agree on almost all significant areas of policy. This leaves the people disenfranchised: they can vote out the monkeys but not the organ grinder. So voting is now a less important democratic instrument than the second means: the ability to register our discontent during a government's term in office.

Monbiot does not take the next logical step: to conclude that voting for or against any of the monkeys is futile as long as the same old organ grinder is playing the tune. Most folks think that voting in every election is the limit of their civic responsibilities, and are aghast if you say that you are opposed to voting on principle. Yet they voice little dissent during any given monkey's term of office, and show no recognition that the same old organ grinder is still in charge (in fact, they usually think that their monkeys are far superior to those monkeys from the other party, whom they demonize relentlessly).

Sadly, it's not easy to see how we can rid ourselves of the organ grinder (whose organs, it seems to me, are the organs of state power). But one helpful step would be to strengthen the fiber of civil society, rather than to focus so incessantly on the doings of the monkeys in various positions of government power. As the bumper sticker says: "Don't vote: it only encourages them."

Posted on 2004-08-08 at 20:35. File under politics.

~ link ~

Going Public

Further thoughts on copyright extension.

While at IETF 60 last week, I got to thinking about the ethics of publication. To publish something is, literally, to make it public. Last year, I decided that whenever I publish something I would put it directly into the public domain. This may seem fairly radical: why not just go with the flow and let my works pass into the public domain 70 years after my death? The problem with this line of reasoning is that politicians and pressure groups are quite likely to extend copyrights again and again (you don't think the Sonny Bono Copyright Extension Act was the last such abomination, do you?). In fact, it would not surprise me if some future Congress decided to extend copyrights indefinitely, in which case my works would never pass into the public domain. One solution would be to will all my works into the public domain at my death, but it seems more straightforward to place them into the public domain immediately. To me, the public domain has become an ethical issue: if I ever want my works to pass into the public domain, I must choose to do so now rather than to have their fate driven by oligarchic legislators and corporations.

Posted on 2004-08-08 at 16:49. File under publicdomain.

~ link ~

2004-08-06

A Limerick

In homage to the father of the Internet.

Last night after the IETF plenary session I happened to be part of a small gathering of geeks who among other things were speaking of how IPv6 will eventually supplant IPv4, so I spontaneously (well, after some coaxing) came up with the following limerick:

There once was a man named Al Gore,
Who thought that the phone could do more;
He invented the Net,
But we'll do better yet,
For he only developed 'v4.

To the universal deployment of IPv6!

Posted on 2004-08-06 at 07:21. File under technology.

~ link ~

2004-08-05

Scribing

More IETF-ing.

While at IETF 60, I have acted as the "Jabber scribe" for meetings of the XCON (two sessions!), MARID, and NEWTRK working groups, and I just promised newly-minted WEBDAV co-chair Joe Hildebrand that I would scribe for his meeting this afternoon. Scribing involves transcribing the IRL discussion into a Jabber chat room (there is one for every IETF WG over at xmpp.org) so that people who are not in the room can try to follow the discussion. It's a dirty job but someone has to do it. Note to WG chairs: it really helps the scribe if you ask that people who comment state their name -- even if they've stated it ten times before. Scott Bradner was quite good about this in the NEWTRK meeting this morning and it was much appreciated.

Posted on 2004-08-05 at 14:17. File under jabber.

~ link ~

2004-08-04

Speciesism

What is a presentity?

RFC 2778 describes the term "presentity" as follows:

Presentity (presence entity): provides presence information to a presence service.

This seems straightforward if inelegant. So imagine my surprise when, in discussing the nature of presentities during one of the meetings of the SIMPLE WG at IETF 60 yesterday, it was asserted that a presentity is generally and correctly understood to be a human being -- at which point I got up to the mic and opined that anyone who seeks to limit presentities to human beings is engaging in speciesism. There was a smattering of nervous laughter but I think most people thought I was joking.

I was not joking. Herewith my explanation.

A presentity is an entity that provides presence. In the context of a network, an entity is any addressable thing on the network. In the context of a communications technology, presence is, at root, a boolean indication of whether or not an entity is available for communication. What kind of things might be available for communication over a network? People, yes. But not just people: bots, chatrooms, applications, services, routers, servers, firewalls, gateways, appliances, devices, and much else besides can be networked for some form of communication. Is the firewall or router or web server up and running? That's presence. Is the chatroom functioning? That's presence. Is the bot able to provide answers right now? That's presence. Is the pubsub service sending out Atom/RSS feeds? That's presence. Is the workflow application down? That's presence. Is the coffee maker empty? That's presence. Is the cat on the mat? That's presence.

Thus my charge of speciesism. Any entity that could communicate or provide information on a network is potentially a presentity. Limiting presence to humans is misguided and unnecessary.

Presence: it's not just for humans anymore.

Posted on 2004-08-04 at 13:41. File under jabber.

~ link ~

2004-08-03

A Meeting With The Editor

RFC Editor, IRL.

I just chatted face to face with Sandy, Mieke, and Allison from the RFC Editor and with Michelle from the IANA (hope I spelled everyone's names correctly!). I'm not sure whose bright idea it was to bring the people behind the RFC Editor and IANA functions to IETF 60, but a bright idea it was! It really helps to associate some friendly faces with both the RFC Editor and the IANA, rather than seeing them as faceless functionaries. Plus I gained some insights into how the RFC Editors work, and how I can make their lives easier (e.g., what information they need from me before the XMPP Internet-Drafts go to "Author's 48 Hours"). While I was a bit shocked to hear that this was the first time the RFC Editor and the IANA have attended an IETF meeting "IRL" (perhaps they wanted to shield these gentle editors from the terrifying reality of so many geeks), I certainly hope that this is the start of a tradition, and will be communicating that to the appropriate authorities!

Posted on 2004-08-03 at 16:13. File under jabber.

~ link ~

2004-08-01

Truckin'

Protecting my Mac.

I'm so hooked on my PowerBook that I am going to want to bring it to the office all the time. The only problem is that I really like to bike to work. Perhaps a MacTruck is the answer (thanks to DizzyD for the link).

Posted on 2004-08-01 at 15:11. File under technology.

~ link ~

IETF-ing

Arrived in San Diego.

I'm in San Diego this week for IETF 60. Joe Hildebrand and I just arrived without incident -- I'm sitting in the security tutorial whereas he's in the training session for new WG Chairs (since he got suckered into, er, helpfully volunteered for, being co-chair of the WebDAV WG).

Posted on 2004-08-01 at 15:01. File under technology.

~ link ~

What You Can't Say

On questioning the unquestionable.

Paul Graham's essay What You Can't Say challenges one to think the unthinkable, question the unquestionable (at least as "unthinkable" and "unquestionable" are defined in current society). It's an attitude that geeks and heretics work to inculcate, and that Graham mostly lives up to (or so it seems); yet Graham does not always practice what he preaches. For instance, he blithely assumes that sport utility vehicles ("SUVs") are evil and that the only reason car companies developed SUVs is that their male customers wanted something more macho than a minivan. First, Graham's assertions are historically inaccurate: the modern-day SUV is a direct descendent of four-wheel-drive vehicles such as the Jeep CJ and Toyota Land Cruiser, which were developed sixty or more years ago, not in the last ten or fifteen years as a reaction to the minivan craze. Second, he provides no reasoning to justify why he thinks that SUVs are more evil than, say, full-size pickup trucks (which are just as big, and often bigger, than SUVs, especially smaller SUVs such as the Honda CRV) or high-performance sports cars (whose fuel consumption is as bad as, or worse than, that of most SUVs). It seems to me that, in this instance at least, Graham is accepting the received wisdom and is refusing to question the unquestionable. So let us think the unthinkable: could it be that SUVs are good? Lots of American car buyers seem to think so (they also love big pickup trucks and racy sports cars). Are all those SUV buyers deluded? Possibly. But it's also possible that they appreciate the improved visibility of an SUV, have lots of gear to cart around, etc. SUVs are really just high-profile station wagons, and I'd bet that SUVs have seriously cut into station wagon sales. Were the station wagon buyers good whereas the SUV buyers are evil? I think not, and I think that Graham is merely spewing forth accepted wisdom in this case.

Posted on 2004-08-01 at 14:01. File under society.

~ link ~

identity...

my back pages

me
home
music
jabber
poems
journal
essays
dotplan
résumé
ism book
contact me
colorado blogs

my group blogs

albion's seedlings
extended conversation
floss foundations
microid development
planet jabber

jabberites

adam nemeth
daniel henninger
google talkabout
hal rottenberg
jeremie miller
kevin smith
mickael hallendal
ralph meijer
remko tronçon
robert quattlebaum

techies

barry leiba
bob wyman
eric rescorla
fred stutzman
future pundit
mike linksvayer
paul hoffman
the speculist
steve o'grady
stowe boyd

wonks

cafe hayek
chicago boyz
the futurist
instapundit
joel kotkin
marginal revolution
michael barone
rand simberg
rants and raves
samizdata

i use...

i support...

i listen to...

fighting censorship...

current threat level...

flying the flag...