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.

Hot on the heels of the Actionstream 0.50 release comes the 0.50 release of DiSo Profile! It can be downloaded from the usual place.

Note: The permissions logic has been spun out into the new permissions plugin.  Make sure your install and activate that plugin first if you have any private data, or it will be displayed to the public.

Changes

• Changed author to DiSo Development Team to show contributions by Steve and Will
• Integrated with new WordPress admin theme (about time we released that!)
• Permissions logic spun out into permissions plugin
• Sidebar widget
• Fix for hCard import button (now link)
• Nicer URL display
• Nicer profile preview

I have just pushed wp-diso-actionstream version 0.50 out. You can download it from the usual place.

Changes

• Changed byline to “DiSo Development Team” to reflect all the contributions by Will Norris (more specific contributors in LICENSE file)
• actionstream_services filter as the way developers add custom service definitions
• Better YouTube support
• Support for many new services: userscripts.org, brightkite, getsatisfaction, backtype, github, and twitter favourites
• Sidebar widgets (actionstream and services list)
• Template tag for services list
• Nicer RSS feed URLs
• Some major refactoring
• Integration with new permissions plugin
• Intelligence in service display when wp-diso-profile is installed

There’s an odd phenomenon that occurs as one transitions from an outsider writing code to someone who actively contributes to a community.  The more you contribute to mailing lists and blog discussions, the more you realise it.  You have an opinion.

You never meant to have an opinion, you just meant to write code.  Let brighter minds decide how it all works and just build the solution.  Code, not specs, not politics.  Re-use what’s out there in new and interesting ways.  Yet this, in and of itself, is an opinion.  The more you contribute, the more you realise that you are no longer just asking that things be made easier for implementors or answering questions about past decisions: you are advocating solutions.

This has happened to me more than once as I have transitioned from community to community.  The first was when I began a project to write my own feed reader (BoxtheWeb) and simultaneously became involved in the Blogger Hacks community.  I slowly went from a hacker who thought feeds were cool and wanted to build stuff with them, to an advocate of the RSS2.0 format.  Somewhere in my coding I decided that format was the easiest to use and the best suited for what I wanted, and I began to advocate.

Next was JSONP.  One of the few things I have advocated that gained much headway fast (through nothing I did, I’m sure, but still exciting to see).  Yahoo, coComment, del.icio.us, and others all jumed on the JSONP bandwagon and I was happy.

Other formats got either on my “good side” (OpenID, OAuth, POSH, Microformats) and my “bad side” (ATOM, EAUT, PortableContacts) for one reason or another.

Ridiculous.  Sure, solutions should be chosen based on technical merit, but who gave me (or anyone) the right to decide which technologies have merit?  It’s time to get back to basics.

If it works.  That’s the key.  Working code.  RSS, ATOM, ActiveChannel, hAtom, or a list of URLs in a text file… really, I don’t care.  As long as the data is there and I can read it, I can write code.  Who cares if EAUT takes off or if http://me@you.tld/ remains valid?  If people can log in: we win!  Not only is there not One True Format, there is no long-term difference between formats.  Sure, there may be reasons to choose one over another, but ultimately it’s just data.  What users (or, even better, developers) can do with that data is what’s important.  These days, we’re better at working around the deficiencies of services (*cough*twitter) than building ones that do what we want anyway.

Groups seems to be a very popular concept on the social web.  Facebook, Myspace, Orkut, last.fm, Ma.gnolia, FriendFeed (rooms) : everyone has groups.  How do we think about these groups in the context of tearing down walled gardens?  Do we think of places like Ning that replicate all this functionality in a more open ecosystem?  Or do we push further into a more decentralized way of thinking and collaborating?  Try the following links out:

• DiSo: Twitter
• DiSo: Identi.ca
• DiSo: Technorati
• DiSo: Ma.gnolia
• DiSo: del.icio.us
• DiSo: Upcoming
• DiSo: Flickr
• DiSo: backtype

What do you think?  Besides being a bit rough (some unrelated data sneaks in), this seems like a very good snapshot of what is going on in and around DiSo : better, perhaps, that any of the “official” sources.

I would maintain that on the Open Web we can see two different kinds of groups: ad-hoc and gardens.  Both could be maintained by the same software (which I would love to build, but will not be upset if the lazyweb beats me to it!)  Ad-hoc groups are the simplest: let a user choose one or more defining keywords and then display content from all over the social web that fits that tag (with options to filter by blog, microupdate, bookmark, event, etc).  Done.  A group is born that you can track and reply to and interact with (with appropriate links back to the original service, of course, no extra comments layer like we see in FriendFeed if we can help it).

Gardened groups would be a step more formal, and would be the open variant of existing walled-garden groups.  Group administrators (“gardeners”) could choose a group name/shortname and keywords.  They could then choose to have the group not follow certain services (for example, if no photos would be relevant, not track Flickr) and could also add other relevant feeds/respose links (ie mailing list RSS feed with mailto: links for the “reply” function, code repository commit feeds, etc) and links to relevant pages that are static content (wikis).  Content coming in from all sources could be pruned to hide content that matches the keyword(s) but is not relevant.

Feeds and OPML files should be provided to go along with groups, interaction links should make it into the footers of feed item bodies.