Re: WebFinger compromises

On 31 October 2012 08:45, Brad Fitzpatrick <bradfitz@google.com> wrote:

> 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.)
>

+1 on everything