I’ve been thinking today about distributed commenting. Better known as @replies. This is the idea where the comment author can have the option to own their comments on a blog post by having them syndicated through a provider of their choosing. They may show up on the target site as well, but the comment author owns the permalink.

Of course, we’ve deployed the technology to solve this. Salmon. I haven’t quite got this blog enabled yet (any day now), but when I do you’ll be able to comment here from your own site or a StatusNet or RStatus instance. It’ll show up here, and I’ll be notified, but you own the permalink.

This was possible before Salmon, using Trackbacks, but Salmon is much more robust and delivers the full content of the comment to the target site so that it can be properly syndicated.

You may not want all your comments on other sites showing up in your “main stream”, depending on the services you use and how they’re configured. That’s fine. That’s a UI problem on your provider’s end, and there are many ways to solve it (allowing a post to be marked “do not publish to main stream” seems the easiest).

Now for the hard part: UI. You don’t want to flip over to another site or app to comment. So unless you’re using one of the super aggregators that does not yet exist with built-in Salmon magic, what do you do? The site author needs some way to let you comment with UI here, but authenticated as yourself and with content owned by your provider.

Thankfully, we have OAuth, AtomPub, and discovery protocols. They’re a bit of a mess (everything that evolves over time is), but it’s slowly stabalizing and I can already reccomend some best practices. Ask the user for their WebFinger ID (use a nicer way of asking, ofc 🙂 ) — this could be singpolyma@identi.ca, or http://identi.ca/singpolyma, for example. If WebFinger discovery fails and you can interpret the ID as a URL (you probably can), then hit that. If it succeeds, check for a type=”application/atomsvc+xml” link. That’s your AtomPub endpoint. OAuth does not yet have a WebFinger-compatible discovery mechanism, so attempt OAuth discovery on the URL you have, the AtomPub endpoint, and the rel=http://webfinger.net/rel/profile-page link in the WebFinger result.

You now have an AtomPub endpoint and an associated OAuth endpoint. Unfortunately you may need to be set up to do OAuth with this particular provider, so we may be stuck (though you can always try a blank consumer token/secret pair, since more and more sites are supporting that). If you can get authorization, then you’re done.

While this seems complicated on a technical level, the UI is all very simple. You ask them where they blog, they tell you, you find out if they are set up to handle this and if so, you send them through an OAuth loop. You store the OAuth result in a cookie (maybe only if they checked “remember me”) so that you don’t have to do it a lot. When they post a comment using your comment forms, instead of saving the data you send it off to their site via AtomPub with an in-reply-to value set as your post. Poof.

A Small Extension

Assuming you followed all that, there’s one more thing you might want to do. You as a publisher might want to host all your comment data on some other site (say, identi.ca). With the above setup you can (just set in-reply-to correctly and you can do anything), but what about users who don’t have their own blog/microblog somewhere? For these users it should be fairly simple to set up a dummy/anonymous Salmon service, that gives OAuth automatically to anyone who asks and then sends Salmon slaps of content it receives over AtomPub. An AtomPub-to-Salmon proxy, if you will. Users who comment and don’t have an ID just have their content pumped through there, and you don’t even have to host anything! Awesome!

Just a note that my XRDS-Simple plugin has undergone some major refactoring as part of the DiSo project. It now lives at WordPress Extend.

Take 2! Now enhanced with XRDSs! Eran has blogged about the changes and the initial vendor support.  This plays right into my dream of infinite interop.  I’m quite happy about how small the spec is now that it just rides on XRDSs.  There’s some weirdness (need two XRDs, can have one XRDSs reference another).  Eran has explained his reasoning to me and it makes sense, but I’m still not convinced that it’s necessary.

Anyway, I should roll out a new XRDSs and OAuth DiSo plugin soon with support for draft 2.  And new examples.  There is an alternate PHP class that Eran says will be including support. I will probably use that when it comes out, but I’ll bootstrap with JanRain Yadis and the standard OAuth PHP class for now.

Eran finally released the XRDS-Simple Draft 1 spec. Chris Messina has some great thoughts about how this fits into DiSo, and Eran has done some good explanations himself.  I’m just going to give some of my own thoughts.

First off, forget whatever you think about related standards, like XRDS or XRI. If you dislike OASIS, can it. I’m sick of the fighting and just want the web to *work*.

I’d like to talk a bit about my vision of infinite interoperability, which is facilitated somewhat by XRDSs. Little to none of this is implemented today.  I’m not expressing a pragmatic “let’s build this now” but a hope for what I would love to build in time.  I’m going to use brands familiar to me – if you hate them, pretend I used different brands.

Imagine this: Flickr is an OpenID consumer with OAuth as its authentication standard on all APIs.  They have moved all their content listing, posting, and editing features over to APP (yes, APP supports binary data, like images).  They are using XRDSs for discovery of the endpoints to *all* APIs.

I write a website.  This website lets you easily create collages of images from free sources for use in projects (I dunno, pick a more useful project idea).  You log in with your OpenID and create a collage.  You can print it out and embed it on your site, but you want to share with friends.  You click a ‘share’ button and are taken to flickr where OAuth authenticates you (maybe using shortcuts since we know your OpenID already) and posts the image to your account using APP.  It knows where all the endpoints are because of XRDSs.

How is this different than what can be done with the Flickr API today? Just wait.

Your friend sees your collage and wants to make their own.  They also come to my site.  They also click share.  They do not use Flickr, but rather Zooomr, for their images.  Zooomr is also OpenID+OAuth+APP+XRDSs enabled.

My site *does not* have to know about Zooomr.  You can simply entry into a settings box “zooomr.com” and my site with *automatically* (XRDSs) find the endpoints to authenticate (OAuth) and post (APP) and your friend can share their image.  I support four standards and get access to *every* photo sharing solution, without even knowing they exist or having to care.

This plugin now lives at WordPress Extend.

I have updated my XRDS plugin for WordPress to allow for deleting XRDS services, and also to have a nice configuration UI for delegating an OpenID.  I have updated the tarball for both the XRDS plugin and the Pempeth plugin to include the new version.