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.
This site runs on idno: an open source social publishing platform that I've been working on for the past few months in my own time.
You may know that I co-founded Elgg, the open source social networking engine, which is used by the likes of Oxfam, NASA, the World Bank and several national governments as a social intranet and learning platform. The original thinking around Elgg happened a decade ago. Given that, you shouldn't be surprised to learn that my original thought experiment was: What decisions would I make if I was building Elgg today, in 2013? What would I do the same way, and what would I do differently?
Some technical decisions
I knew that I could make a faster social networking platform, with a better templating engine, and a much smaller codebase - even while sticking to PHP as an underlying scripting language. Partially that's because PHP 5.3+ is a much better development platform than earlier versions. It's also because there are now some well-tested, intelligent back-end frameworks, like Symfony 2, and front-end frameworks, like Bootstrap.
One of the major decisions I made when we built Elgg 1.0 was that not only was it a hassle for plugin developers to write their own database schemas - it was undesirable to the point of being dangerous. We effectively faked a NoSQL schema in MySQL by creating a data model around entities (first-class objects like users and blog posts), metadata, annotations and relationships. People were taken aback, and it was row-intensive, but it worked, and it continues to work today.
Nonetheless, today we have NoSQL, so #idno is based around MongoDB. This means there are far fewer database transactions involved - and adding new data to an object is incredibly easy. Together with a plugin architecture based on lazy loading, and Symfony's excellent observer pattern support, as well as the framework code I've built, I'm able to write a new plugin in an hour or two. That's important for a system I'm building in my spare time!
Meanwhile, all of the things about #Elgg that were great - a plugin architecture, granular access permissions - are intact. And on top of that there's a faster framework, and a responsive front-end that works really well in a mobile browser. Great!
But that's not the end of the story.
The #indieweb community has existed for years as a force to advance the state of the independent web, and to promote ownership of our own spaces. IndieWebCamp is an annual event for creators to discuss their platforms, technologies and ideas.
One of the big concepts to come out of #indieweb has been #POSSE: Publish (on your) Own Site, Share Everywhere. The idea is that your friends or followers shouldn't have to join your site to engage with you; you should be able to post on your own site and be read on Twitter, Facebook, Foursquare, or wherever they happen to be. idno has built-in plugins for status updates, blog posts, images, checkins and events. Correspondingly, it also has plugins to #POSSE this content to Twitter, Facebook, Foursquare and Flickr - and writing more would be trivial.
That's just as well, because I've committed to only post on my own site and copy to third parties (where that's possible).
Reinventing the social web
This year, though, something else happened. Using Microformats 2 (a way to very simply embed meaningful markup into any web page) together with Webmention (a way for any web page to lightly ping the pages it references), the community participants created the first indieweb decentralized comments thread.
Using nothing more than the markup on their own web pages and a very simple protocol, the participants created the basics of a decentralized social community, where each comment is hosted on its owner's own site, but nonetheless forms a coherent, easily-readable narrative.
This is a very big deal.
It's a completely different model to traditional social networking, where content typically doesn't bleed outside the walls of a specific social site. It's also different to previous decentralized social networking efforts, which have been in many ways more sophisticated, but much harder to join in with. Because a simple IndieWeb-compatible social tool can be built in an afternoon, just as a simple RSS-compatible tool can be built in an afternoon, these concepts have a much greater chance of succeeding.
Needless to say, idno is now a first-class participant in the decentralized IndieWeb social community. I've implemented IndieWeb comments, and moved immediately to also implement decentralized events that anyone can RSVP to, as well as decentralized likes. It also integrates with Firefox's brand new Social API.
You can browse the web and reply to any page, on a site that you truly own.
As more sites and platforms implement the IndieWeb social standards, those interactions will become correspondingly more social. For now, though, you can go ahead and interact with the web already.
Beyond that, idno will continue to develop over time as a community platform in itself. I'm using it here on my own site as a single-person publishing platform, but it doesn't have to be that at all, and all those Elgg-style features will continue surface as time goes on. But there's a big, wide web out there, and it's important to embrace that as widely as possible.
idno's homepage is here. Meanwhile, I continue to do work I'm proud of in my actual job, working for latakoo to facilitate media storage and transfer for video professionals and the broadcast news industry. We're talking about using decentralized social networking there too - but more on that another time.