Re: WebFinger compromises

Screw 'backwards compatibility' with any existing wf site. And screw writing a spec.

I've written a more than capable client toolkit that supports the sites and features I cared about. You can too.

Build it or go home. We can specify how it works once it actually does.

--
http://josephholsten.com

On Oct 31, 2012, at 23:34, "Paul E. Jones" <paulej@packetizer.com> wrote:

> Brad,
> 
>> To everybody who recently saw me rant about WebFinger in person
>> recently, hello again.
> 
> Oh, I wish I was there... ;-)
> 
>> 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?
> 
> Cool! Always wondered where the name came from.
> 
>> -- I added Google's WebFinger support
>> (https://groups.google.com/group/webfinger/msg/e8df6402708841ea)
> 
> That also answers questions kept asking when I mentioned Google had support for it.
> 
>> -- 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.
> 
> That WF has done.
> 
>> (trying to establish that I'm a friend here)
>> 
>> That said,
> 
> (gulp)
> 
>> -- this is the slowest moving community ever (I accept part of the blame
>> here)
> 
> No kidding.  Some I-Ds take 8 or more years in the IETF.  By the time we make it perfect, the "opportunity has set sail"... I've seen that happen several times.  Then people ask why we don't standardize some things.  It's the process sometimes.  Standardization is not always worth it.
> 
>> -- 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)
> 
> The current language actually isn't political compromise, but more my desire to not break backward-compatibility any more than we have to.  Current spec recognizes, for example, that Google's WF server serves up XML.  Clients expecting XML will still work.  So long as any WF server wants to support both, those clients will work.
> 
> Going forward, XML is optional and JSON is mandatory.  I wanted to mandate both, but lost that argument.  (Still, supporting both is simple.  My server does both and will honor the Accept header.  It's trivial to do.)
> 
> At some point, I will publish my server code.  It's just a simple Perl script, but shows how trivial it is to implement a WF server.  It does both XML and JSON and I do wish we would continue with both.
> 
> Further, I accept the preference for JSON and only putting the requirement there.  But the fact is that any web resource can return ANY format.  This is a basic part of HTTP and the reason the Accept header exists.  So we should design the service such that we can support whatever the next hot format is.
> 
> So, my position is:
> 1) Let's not just kill XML because we decided we do not like it this week (killing all hope for backward-compatibility)
> 2) Let's have a web service that could serve XML or JSON or next-hot-thing (i.e., future-proof it)
> 3) Let's use HTTP the way it is supposed to be used and allow the "Accept" header to work via /.well-known/host-meta.
> 4) Since host-meta.json is already defined (and I would have argued against it, but it's there), let's fully embrace it.
> 
>> -- 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*.
> 
> I'd prefer not to for the above-stated reasons.  Note that only JSON is required.
> 
>> -- 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.
> 
> We support both.  RFC 6415 defined the base for 2 round trips.  The current WF spec adds that extension to allow for one round trip.
> 
> And both are trivially implemented, so simple it can be done via static files with an Apache server:
> http://www.packetizer.com/webfinger/server.html
> 
>> I will continue to fight for Google's WebFinger support, but I'm not the
>> only one losing patience.
> 
> You're right there, which is why I'm serving the role of editor.  I'm personally pretty happy with the way things are currently defined.  Aside from the vast number of comments regarding privacy, I'm not hearing a lot in the way of technical issues.  I'd like to move forward.
> 
>> Everybody please hurry up, simplify, then hurry up.  I'll help however I
>> can.  I'm not sure whether this was helpful.
> 
> It's doesn't get much simpler than this:
> 
>   curl https://packetizer.com/.well-known/host-meta.json?
>        resource=acct:paulej@packetizer.com
> 
> Now we need to just move on to agreeing on some useful link relations for WF.
> 
> Paul
> 
>

Received on Thursday, 1 November 2012 00:00:39 UTC