Well, I know it's lame to say that it's different this time, but it seems to me that "tools will save you" for XHTML was a stretch at best. The intended audience of WebFinger publishers is significantly different and smaller than that of XHTML, don't you think?

To distill what I'm saying here:

In my opinion, the biggest challenge with WebFinger is not the protocol's details. The issue is adoption. Since I believe we've passed the threshold of "a provider could implement this in a day," regardless of protocol minutia, the difficulty is now gaining forward momentum through increased usage.

No I don't think the door is closed at all. DeWitt made some great suggestions about XRD and I think all of them were adopted. Your feedback here about usability makes sense to me, but it can be addressed through tools not spec changes. The discovery process you outline (5 steps) is the same as the one using XRD (assuming you skip/cache the DNS step). The only difference is the document format, which I maintain is irrelevant. We have multiple vendors (Google, Yahoo, etc) that agree on *something* and implemented it so we can actually use the protocol for some open federation; the end-result should be the focus.

All said, I think if you provided a free JSONP webservice that did the XRD to JSON conversion/discovery as you've described, that would be a boon to developers.

A web service for JSONP usage of WebFinger will exist regardless of the format of the discovery documents, so this is not a compelling argument.

Similarly, I've heard the Mozilla guys have prototyped rendering the XRD documents with XSL to make them interactive to end-users. Type acct:foo@example.com into your browser and now you have something you can interact with.

Is such usability of XML/XSL an argument in favor of XML? I would argue *no*. This simplifies things for one use-case (browser rendering) while making it hard for others (javascript apps).

This is what I mean by saying the formats are irrelevant: Everyone has a use-case they think is compelling and thinks the format should follow suit (rfc822, json, xml, yaml, html, text, asn1, protobuffers). Ultimately, programmers will connect all of these various pieces, regardless of format, and everyone will be happy. We just need to agree on *something* that *could* work and start making forward progress with its usage.

The most helpful thing you and others can do is write bridges to/from your format or use-case and provide it for others to reuse. If you find holes in the *functionality* provided by the discovery documents (e.g., no way to indicate prioritization) then that's something that needs to be addressed.

However, the value-add of Superfeedr goes beyond their feed-fetching capabilities. What's most interesting to me is what these services do beyond the raw interactions. For Superfeedr this is bridging feed and ping formats into Atom, XMPP, and PubSubHubbub. And there's room for much more! -Brett