Re: [apps-discuss] WebFinger compromises

[Peter Saint-Andre <[e-mail]>]

[ +cc [e-mail] given that the spec is now an
Internet-Draft... ]

On 10/31/12 9:48 AM, Dick Hardt wrote:
> +1 on everything. 
> 
> A simple, easy to understand spec that solves the major use cases
> released soon is far superior to kitchen sink spec that solves all use
> cases that is released in a year.
> 
> JSON only (if that is not obvious, you need to write some code this decade)
> 
> 1 round trip vs 2 round. Pick one that is simple to implement. Let's not
> get caught up in optimization. Brad's comments below seem sane (as usual)
> 
> -- Dick
> 
> 
> On Oct 31, 2012, at 12:45 AM, Brad Fitzpatrick <[e-mail]
> <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]> 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.)
>>
> 


-- 
Peter Saint-Andre
https://stpeter.im/