Uncategorized

WebFinger for Facebook and Twitter

I’ve just published webfinger-unofficial, a stand-in WebFinger server for major sites that don’t implement it themselves. It currently has implementations for Facebook and Twitter, deployed at these endpoints:

It’s just a little side project, and it’s not hugely useful on its own, but it is a step toward implementing OStatus bridge apps for more of the major social networking sites.

Feedback and pull requests are welcome!

Standard

6 thoughts on “WebFinger for Facebook and Twitter

  1. Nice. I wonder if we should patch http://code.google.com/p/webfingerclient-dclinton/ to support alternate hosts for services that don’t support it natively…

    I could go either way about the merits of this. On the one hand, their opting out of the ecosystem should in theory mean net less traffic over time (all other things being equal). On the other, having large identity providers from the outset helps bootstrap the number of identities and may incentivize more clients to participate.

    Thoughts?

  2. thanks! yeah, i haven’t fully nailed down the client side details. it does accept user identifiers with both domains, so if clients transform the user identifier, existing client libraries may work as is. yours does, for example:

    http://webfingerclient-dclinton.appspot.com/lookup?identifier=snarfed_org@twitter-webfinger.appspot.com

    however, the host-meta files have the official domain (e.g. twitter.com) in <hm:Host>, so if the client checks that against user identifiers, it may complain. that’s probably why the webfinger.org test client doesn’t work:

    http://webfinger.org/lookup/snarfed_org@twitter-webfinger.appspot.com

    as to the merits, if it was a fair fight, and all of the sites were trying to build market share from the same clean slate, i’d agree. unfortunately, the audience is already pretty saturated with a short list of majors – fb, twitter, g+ – which don’t support the federated protocols, with minor exceptions like google’s webfinger.

    also, third party hacks like this are way less useful than built in support, for both obvious reasons (user experience, features, compatibility) and less obvious ones (adoption, the ban hammer).

    finally, full disclosure: my main motivation for hacks like these is selfish. i want to interact with my friends online, but i don’t want to have to use all of the different sites they use. this kind of thing will help me narrow down the clients i have to use. i care about the greater good too, and i’m ready to participate in the development communities, but it’s not always the single biggest thing driving me. :P

  3. Cool to see these unofficial WebFinger endpoints – makes it a lot easier to produce powerful proof of concepts.

    Some feedback on your host-meta-file:

    You don’t seem to be following the final specification of it, rfc6415. The final specification includes no specification of any “host”-tag.

    Also: Why specify the title “Resource Descriptor” for the LRDD-link? Why not do just as suggested by the examples in rfc6415?

    Also – supporting JRD in addition to XRD would be nice :)

    When it comes to the WebFinger document for Twitter:

    It would be nice to see both hCard and XFN links in the WebFinger file as Twitter supports both well. The relation types “http://microformats.org/profile/hcard” and “http://gmpg.org/xfn/11” are usually used for that, see eg. http://code.google.com/p/webfinger/wiki/CommonLinkRelations

    I would also suggest changing and removing the avatar link for Twitter users as Twitter says that the current “method should only be used by application developers to lookup or check the profile image URL for a user. This method must not be used as the image source URL presented to users of your application.” – as a WebFinger client I would assume that any avatar in “http://webfinger.net/rel/avatar” would be relatively okay to use in image tags.

Leave a Reply

Your email address will not be published.