WebFinger compromises

To everybody who recently saw me rant about WebFinger in person recently,
hello again.

To everybody else, a brief summary:

-- I was an early WebFinger evangelist. I remember discussing it at
conferences for years before it sorta became a thing. I think I even named
it?

-- I added Google's WebFinger support (
https://groups.google.com/group/webfinger/msg/e8df6402708841ea)

-- I think it's critically important for the Internet to preserve
user@host.com hierarchical identifiers before email gets too passe and
we're stuck with single-namespaced walled gardens.  It's on us to make
email-looking identifiers more useful to compete with all the latest
proprietary silo hotness, before the people of the internet no longer
recognize them.

(trying to establish that I'm a friend here)

That said,

-- this is the slowest moving community ever (I accept part of the blame
here)

-- can we please stop changing things?

-- JSON, XRD, great, whatever.  But let's just pick one.  If JSON is now
the hotness, let's pick *only* JSON.  Specs that say "X is required but you
can maybe do Y if you want to" just reek of political compromise to gain a
certain party's favor.  Look at OpenID 2.0.  (I remember being sad about
those political moves too, but I had lost the energy to fight)

-- My recommendation: just remove all mention of XRD from the latest
WebFinger spec.  Yes, this is counter to my "please stop changing things"
bullet earlier.  But WebFinger has a better chance of success if it's a
simple spec.  And you're not breaking compatibility with anybody because
*nobody uses WebFinger*.

-- 1 round trip, 2 round trips. Don't really care. 2 round trips keeps the
spec simpler and the 1st will be highly cacheable (Expires: weeks), so it's
1 round trip in practice, but I won't fight (too much) *optional*
parameters in the 1st request to possibly skip the 2nd request.  It worries
me, though.  I'd rather see that optimization added in a subsequent version
of the spec, so all 1.0 implementations have then shown that they're
capable of performing the base algorithm.  I worry that too many servers
will implement the optimization and then lazy clients will become pervasive
which only do one round trip, thus making the "optional" optimization now
de facto required for servers.  So I'd really rather drop that from the
spec too.  Let's add it only later, once it's shown to be needed.  As is,
clients could even fire off two HTTP requests in parallel to reduce
latency, one for host-meta and one optimistically for the presumed
host-meta location in cases of big hosts that rarely change, or expired
cached host-meta documents.

I will continue to fight for Google's WebFinger support, but I'm not the
only one losing patience.

Everybody please hurry up, simplify, then hurry up.  I'll help however I
can.  I'm not sure whether this was helpful.

- Brad

(If any of the above is offensive to my employer, I'm speaking as myself.)