Here's how it works.
First of all, Idno has a plugin system, that allows new functionality to be added system-wide. As well as new kinds of content like slide presentations, plugins are available that interact with the APIs of Twitter, Facebook, Foursquare and Flickr.
When I install any of those plugins in Idno, I'm taken through a process where I register my Idno site with the third-party API. Each of those sites has a slightly different process, but in each case it takes about 30 seconds.
Once the link has been made, the plugin shows up as an option in Idno's user settings screen. I click "settings", and then click a button to link my account to the site:
This is exactly the same procedure as logging in with any of those sites, or attaching any third-party application. It's about two clicks: in the case illustrated above, I'm taken to Twitter, which asks me to confirm that I want to give Idno permission to use my Twitter account, and then taken back to my Idno settings. Internally, my OAuth token for that site is saved to my user account.
Here's where things get interesting.
Remember I said that Idno's content types are also provided via plugins? There's a plugin for status updates, for photos, blog posts, events, etc etc. Whenever I want to add a new content type to Idno, I add a plugin. (They're really easy to write; the presentations plugin was written in about an hour, while I was recovering from a root canal operation.)
As well as descriptive content type - "status update" - each plugin announces a generic content type that maps to those used by the activity streams specification. A status update is also a "note"; a blog post is an "article". This allows plugins to extend functionality for certain kinds of content without dictating which plugin you use for that content. Someone can add extra logic for status updates, while not caring which status update plugin I actually use.
When I post new content, the system pulls up an interface supplied by that content's plugin, and also asks any syndication plugins if they're able to handle content of this type. So when I click on my "status update" button, Idno asks plugins if they're able to syndicate content of type "note".
Idno automatically renders some buttons for me based on those plugins. If I enable the "Twitter" button, my content will be syndicated to Twitter when I post it. If I enable the "Facebook" button, it'll go to Facebook, too. If I later decide to add a button for Path or LinkedIn or Friendster via a plugin, it'll show up there, and work in exactly the same way, without me having to change any of the status update plugin.
When I hit Save, the syndication plugin receives information about the content type (but not which plugin created it), as well as information about my account. It retrieves my API token from when I linked my account through my settings panel, and uses that to sign an API request posting the content to that site. It then retrieves the URL of the syndicated content and saves it to the local content in Idno, so a "syndicated to" link can be displayed underneath it. (Check at the bottom of this post's page: you'll see a link to Twitter.)
This process works throughout Idno. Photos (of generic type "image") can be syndicated to Facebook, Twitter and Flickr, and while the logic is different for each site, the user interface flow is the same for each one. This works whether I'm posting from a laptop or a phone, and whether I'm on the standard web interface, a custom interface or the API.
It's important to note that none of this takes much time, for any of the parties involved. Writing a content plugin takes about an hour; writing a syndication plugin can take much less time, if the third-party API uses OAuth. Site admins can install a plugin and set it up in a few minutes. The process for the user takes mere moments, and that's the most important thing.