WebFist support

[konklone]

python-webfinger tracks a webfist property, but doesn't seem to do a fallback to WebFist itself. Is this something you're interested in supporting?

It's possible that WebFist itself could use an update -- it doesn't use HTTPS (which is why client.webfinger.net's attempted WebFist fallback is broken). But its whole point is to act as a lookup/delegation service, not a WebFinger endpoint itself.

For more details on how WebFist works and why you can trust it, check out the original WebFist blog post.

[jcarbaugh]

Yeah, I read the post and considered it, but decided to hold off for now because I'm not sure of how widely used WebFist is or will be. The recent changes show, if I'm understanding correctly, that there has been one new email added (today) since July 11. Ouch.

BUT, there aren't really any downsides, right? Just an extra request to WebFist (which will probably fail since it's not used that much) after the initial WebFinger request (which will probably fail since it isn't widely supported). I might do it just for the hell of it.

[konklone]

...and that one email today was me.

Yeah, it's definitely not gotten much attention since the initial small burst of energy when it launched. But it's a good idea, maybe it and WebFinger can help each other get some attention.

@bradfitz, since WebFinger's RFC just came out, do you have any energy to breathe into WebFist? Anything we can do to help?

[jcarbaugh]

I'm also wondering... I get the WebFist fallback if the initial WebFinger call fails. What about the specific case you mention where twitter-webfinger.appspot.com responds with a valid WebFinger response, but contains a WebFist rel link? It's not mentioned anywhere I can find that the client should follow that. I'll work on the default WebFist support, but will probably leave that other case up to the developer using the client to handle as they see fit.