Photo by ThinkPublic, http://www.flickr.com/photos/thinkpublic/3042777307/

Eureka Streams, which was announced in late July, is built on the Open Social standard and Apache Shindig. The focus is clearly on (as the name “streams” implies) lowering the barrier to information sharing, in the style of microblogging (think twitter, status.net, and yammer, but also tumblr, posterous, and xxxx). As Ostatic’s coverage put it:

Visually, Eureka Streams is a combination of Facebook, Twitter, and LinkedIn. Personal profiles let workers to put a face to a name, which is particularly useful for making remote workers feel connected to each other beyond a disembodied voice on a conference call. Plugins allow for real-time sharing of business-related information, including the ability to share articles from Google Reader and import bookmarks from Delicious. Powerful search features help employees network and connect with other professionals within the company.

The video (below) shows the polish Lockheed Martin’s put on the framework, which I’d say competes well with any proprietary platform from a design and usability perspective:

There are many more videos on the Eureka Streams site, showing off various pages and their functions.

Drupal Commons, announced back in April and released at 1.0 in the beginning of August, is built as an install profile for Drupal, leveraging that platform’s legendary strength as “community plumbing” and community contributed modules long familiar to Drupalistas building social sites.

In this video Jay Batson of Acquia walks through a preview release:

Also worth checking out are DrupalRadar’s First Look and Review, and Jay’s other videos on the Business Value of Drupal Commons and the Features of Drupal Commons.

Finally, you can try it out yourself by joining the Drupal Commons community and checking out some groups there which match your interests.

Building on the momentum of all the (OpenSocial based) applications they added a few weeks back, LinkedIn is now rolling out events. In this video, Christine Wodtke demonstrates how the application leverages your social graph, showing who in your network is attending various events:

Its a great idea, and I’ve already found or created events for all my conferences coming up. (I’m tempted to create events in the past, as a way of adding conferences where I’ve presented to my LinkedIn profile. The “add an event” flow doesn’t seem to prohibit that, though I haven’t followed it all the way through yet).

I wish the recommendations (which events they suggest you might want to attend) were a bit more precise, but I guess that’s a result of relying on things like “industry” set in your profile (mine is set to “Internet” which must be hard to match on), or job title (“Next Generation Internet Strategist” is not on many event planners’ lists of target job titles), or even education (my educational background is pretty varied and not neatly tied to what I do now). I think it’d be great to allow me to configure the app to add some tags of interests – and maybe let me choose how recommended events get sorted (date, distance, relevancy, or some combination thereof).

It would also be good to have a simple way to get an event’s URL – for now I’ve been to the event’s “page” and clicking on the “Share” link, then pulling the short url out of that message. That results in a url looking like this: http://events.linkedin.com/pub/12514
Rather than one looking like this: http://www.linkedin.com/osview/canvas?_ch_page_id=1&_ch_panel_id=3&_ch_app_id=30&_applicationId=2000&appParams={%22from%22%3A%22my_events%22%2C%22go_to%22%3A%22events%2F12514%22}&_ownerId=2757022&completeUrlHash=gXn-

I assume the nasty url is a result of OpenSocial, in the sense that the hosting site needs to know which application to load and then pass info to the application – but since they are already creating url aliases, why not expose them more directly?

These suggestions aside, it’s a welcome addition which makes LinkedIn much more useful, especially to those not in job-seeking mode.

(If we’re not connected on LinkedIn and should be, here’s my profile).

It’s a very vibrant space right now, with commercial vendors, open source projects, trends, and standards all vying for attention. I’m thinking here of a couple of overlapping categories:

OpenID

A standard, for which there are good open source libraries, but also commercial providers. Increasingly I’m seeing OpenID as one service (often the anchor service) provided as part of a suite. Of course the traditional mainstream web players like LiveJournal, WordPress.com, Yahoo! and AOL (through AIM) are providing OpenIDs as well.

Lifestream and Profile Aggregation

More social networks == more profiles, and more feeds. A number of services/projects have sprung up (I talk about a few below, but there are many others as well) which enable you to aggregate together all of your profiles in a single place. Some are more focused on aggregating all of your feeds – creating your lifestream and letting others subscribe to it; others are focused on aggregating the feeds of your friends, to make it easier for you to follow.

The Data Portability Project, Open Web Foundation, Open Social Foundation, Autonomo.us

These foundations are not focused (directly) on producing software, but on building awareness of and consensus about the need for user freedom on the internet, and publishing open specifications which will lead to a world in which our online identities and data streams can be more easily managed, exchanged, and even migrated from provider to provider.

It would really be a full-time job to keep track of all that is going on in this space, but here are a few I’ve been following / trying out.

Chi.mp

Chi.mp enables each user to create their own domain in the .mp TLD space. You can check out mine at johneckman.mp. Chi.mp provides OpenID, but doesn’t (yet) consume it. (I can use johneckman.mp as an OpenID to log in to other sites, but I can’t login to chi.mp with an OpenID from elsewhere).

Chi.mp also supports a number of services (currently Twitter, Facebook, Flickr, Gmail, Yahoo (mail), and Hotmail). For those which provide activity feeds, chi.mp will pull those feeds into your profile (viewable by others) and dashboard (viewable only by you). There’s also a generic RSS feed import capability, for services (like personal blogs) that Chi.mp doesn’t know.

Finally, Chi.mp also supports your social graph – your friends lists or contacts lists from various services can be imported – from webmail services like gmail and hotmail but also from services like Twitter, Facebook, and Flickr which have contacts or friends exposed via an API.

It’s very highly configurable, in terms of who can see what. You can tag contacts, and tag feeds, and use tags to determine visibility of feeds to groups of contacts. I haven’t yet really figured out what else Chi.mp will be able to do with webmail services – I don’t think I will ever want emails I send or receive showing up in my action stream or on my profile, but certainly being able to leverage various APIs for getting contacts will reduce the need to “refriend” people on each new network.

For now, however, Chi.mp has no way to identify that the “John Doe” you are friends with on facebook is the same person as the “John Doe” who is a contact on Flickr – they provide a simple way to manage contacts (and “merge” the two contacts into one virtual person) but there is still human effort (decision making) involved in reconciling these graphs.

Trufina

Trufina adds an interesting twist in that they are trying to more tightly link online identity to offline. Using a method well known to financial services companies – the ability to answer a short set of questions about your financial history which would not be known to someone who found your wallet in the street – Trufina verifies that the person using the name John Eckman is the same one who lives at a given address and has other “meat space” attributes.

You can see my default public profile here:

I have to say their focus on “criminal background checks” I found a bit creepy: I realize that background checks are important for certain kinds of employment, but it seems like the need (and even desire) to assert a record free of felony convictions should be a niche market, not the default market for an online identity vendor. (Employment verification and educational background verification are said to be in development).

They also then enable you as a user to share various parts of your verified identity with others, including inside a number of social networks. You can create an “ID Card” and show that to only specific folks. There was no way I could find, however, to not show the “Criminal Records Search” section of the ID Card – it seems to always show either “” or “ ” – neither of which makes for high confidence. How about the ability to not show that section at all, if I don’t think it’s relevant, in which case you could also dispense with the rather elaborate disclaimer about criminal record checks.

I also found it frustrating that the default “profile” view – the only one people can get to who haven’t been specifically authorized by you – shows only the Trufina user name. Obviously given the market Trufina is after, and the data that a full profile might ultimately contain, they need to be concerned about privacy. But what if I’m perfectly happy to have people see my first and last name and maybe state of residence and employment?

The key to privacy needs to be control, not defaults which prevent users from making basic data public.

Identity.net

The folks at Identity.net have partnered with Trufina, to link your “Trufina Verified Identity” to an OpenID which can be used throughout the web. It’s a great concept – to be able to demonstrate that the virtual identity a given OpenID represents is tied to a real offline person could be quite valuable.

I’d hope to preserve, however, the option to also have OpenIDs which are not linked to my offline identity. The ability to get the benefits of OpenID (in terms of single-sign-on) without necessarily having all online activity tracked directly to your offline identity is one of the freedoms the internet promises and I’d hate to lose that. (A number of OpenID providers enable you to create multiple OpenIDs that only they know are associated with each other – this enables you to project different identities on different sites).

Like many of these services, Identity.net is in beta, and was having trouble with their control panel when I signed up, so it’s possible I haven’t yet seen what flexibility they offer in creating and using OpenIDs tied to your Trufina identity.

ClaimID.com

I use ClaimID with delegation to use JohnEckman.com as an OpenID. ClaimID also provides a basic profile page on which you can enter links to web sites and verify your ownership of them, as well as display contacts, optionally marked up in XFN (with semantic data about the relationship you have with each contact).

Movable Type with Action Streams Plugin

I use the open source edition of Movable Type with the Action Streams plugin to power JohnEckman.com as a lifestream aggregator, pulling in feeds from various web services. Creating additional plugins to add services to Action Streams is relatively simple, and I’m hosting it myself so I have complete access to the data stored and complete flexibility in display.

The DiSO project has produced a similar plugin (WP-DiSo-ActionStream) for pulling action streams into WordPress (I’m using the OpenID plugin from DiSO on this blog), and there’s an Activity Streams module available for Drupal as well.

Finally, there’s Sweetcron, which I have only just started to experiment with, but which focuses on just managing the action stream aggregation without the extra functionality (and overhead) of a blog or other framework like MT, WordPress, or Drupal. It’s also easily extended.

As all of these evolve, how much ownership and control will users want to have over the content their online activity produces? How much technical understand and effort will they be willing to expend in order to exert that control?

What, in other words, will be the balance between hosted providers (they do all the work but also retain some element of control) and self-hosted open source platforms (you do more work and gain more control)?

Will the central difference between the two options lessen as real data portability becomes commonplace?

It’s part of the larger Glassfish project, and uses Apache Shindig as an OpenSocial container – they demo’d OpenSocial widgets running inside Drupal and MediaWiki – all running inside a Java Application Server.

Video:

This could be a compelling option for those looking to run their own open social containers. It isn’t available in source code form yet, but you can sign up here to be notified when it is available.

I think it’s a very useful concept, pointing out that people’s decisions aren’t binary: it isn’t a single yes/no decision but an active, ongoing negotiation, which determines which services you use and don’t use.

You can also think about the barrier to entry of a new user in a similar fashion. Any time you try out a new application or service there are a few barriers, and whatever the application developer can do to lower those barriers the more users will get over that threshold.

(One of the key benefits of open source, from my point of view, is the relatively low threshold of entry it makes possible – no need to negotiate an enterprise license, sign up for 2 years of support, and get lawyers to agree on terms – just download, install, and try out).

In social web applications, the barrier to entry is generaly sign up – authorization and authentication. Applications running inside containers like Facebook have the benefit of bypassing the authentication problem – by relying on Facebook to determine that you are appropriately logged in to your own identity – but still need to get authorization from you to “install” themselves to your profile.

The problem is that Facebook (or Facebook application developers, guided by the Facebook API) seems to treat this experience as a binary choice: you either install the application or you don’t. From the application’s point of view, you are either a user who has installed the app (in which case you’re in) or a user who has not yet installed the app (in which case you’re out).

Why should I have to install an application in order to be able to see the message my firend sent me using it?

Jonathan Terleski, from Google’s User Experience Team, posted a movie today showing a better way: allow users to experience the application and then – after they have determined it has some value to them – ask for the install.

What do you do, though, if you’re outside the environment of an open social container or the Facebook API? Use OpenID and OAuth.

Keeping the barrier to entry low:

1. Let people have a decent sense of the experience before “creating an account” (or whatever language you use to describe registering). Let ‘em try before they buy, as much as possible.
2. Use OpenID. Enable people to log in to your new service using their existing identity elsewhere. With Yahoo! and AOL on board, and the directed identity features of OpenID 2.0 (which let users click a button marked “log in with your Yahoo! account” rather than remembering a URL) we should see end user adoption of OpenID take off. (It may be “unaware adoption” in the sense that people don’t know it is OpenID being used, but that’s actually a good thing).
3. Leverage their data from elsewhere, using import via Google’s Social Graph API, hCard profiles they may have on other sites, XFN or FOAF notations from sites like Twitter which markup links with microformats, and OAuth to access third party data.

I’m looking forward to seeing more detail on the Ringside Social Application Server next week – looks to offer a very compelling path to bringing social networking features into applications without imposing a high barrier to entry. See also DiSo, Noserub, Shindig, and the Appleseed Project (which may need to change its name to avoid the other Appleseed Project).

Shindig first, direct from the OpenSocial API Blog “Let’s get this Shindig Started“:

Shindig is a new project in the Apache Software Foundation’s incubator (as per the formal proposal) that aims to provide an open source reference implementation of the entire OpenSocial stack — Shindig’s goal is to allow new sites to start hosting social apps in well under an hour’s worth of work.

This am was the initial commit to the Shindig svn repository. In other words, there’s already code, in the best open source fashion:

This commit represents initial versions of the first two components, the Gadget Container JavaScript and the Gadget Server — the latter written in Java. The Gadget Container JavaScript provides code to generate IFRAMES pointing to gmodules.com, offers some basic gadgets functionality (e.g. dynamic height), a layout manager, the edit dialog box, a cookie-based user preferences store, and an option to point IFRAMES at your Gadget Server instance instead of gmodules.com. The initial Gadget Server provides extensible scaffolding for processing gadgets: retrieving XML, parsing it, and processing it into a form that allows rendering of the gadget to a user or retrieval of its metadata.

I won’t likely have time today (or tomorrow for that matter) to dive into this, but it is great to have some actually code in advance of the holiday week.

The second project I’m excited about this morning is DiSo, which is Chris Messina, Will Norris, Steve Ivy and others working on a social networking platform “with its skin inside out,” starting with WordPress as a platform. It’s a chance to take the concept of using XFN, hCard, OpenID, OAuth, FOAF, and related microformats and open standards to create a truly distributed social network.

(See also GigaOm’s coverage from Tuesday which I just found through the news feed in my WordPress dashboard – The Next Social Network: WordPress)

Glad to see both of these projects kicking off in the transparency of the open source world – gives me good hope that we’ll actually make some significant progress on the social network portability front.

(People I’m reading on this include my colleague Sebastian Wohlrapp, Marc Andreessen, Josh Catone, and Jeremiah Owyang – of course there are a gazillion others as well).

Did I miss something somewhere in the API documentation or the Campfire Video? (It has been a busy few weeks, and I would be happy to be wrong).

As I see it, in short: Open Social is not Social Network Portability. It’s social network widget portability.

Open Social enables widgets written to its OpenSocial API to be deployed (without rewriting) to multiple containers, but it doesn’t link my profiles on various networking sites, or allow me to carry my relationships with other people across network boundaries.

So if I make a “photos of my dogs” widget, and deploy it on Orkut and Hi5, I can share photos with my friends on both of those networks, but the two are completely separate. I’d have to log in to Orkut and share some photos there, then go log in to Hi5 and share some photos there.

My friends who are only on Orkut won’t see photos I share to Hi5, and vice versa. If I add someone as my friend on Orkut, they don’t “automatically” become my friend on Hi5.

In fact, as I read it, nobody but me even really knows that these two profiles (one on Orkut, one on Hi5) are the same person.

This mostly helps developers of widgets to run inside social networks. Instead of having to write an application for Orkut, and another for Hi5, and another for X, developers can create one application adhering to the Open Social API, and it can be used on all those networks.

This also helps small social networks, who don’t have a large enough user base to convince widget developers to create widgets for their platforms – the long tail of social networking platforms, if you will.

If anything, this will enable small, silo-style, disconnected social networks to continue to proliferate.

Can anyone point me to any example demonstrating how Open Social is more than described above?

I know the Container API / SDK – which will tell networks what they need to do to become containers – has not yet been released, and perhaps more will be clear when it is. But for now, this seems like a good thing (I do think an open API for widgets is a good thing) but certainly not a great thing.

[Update]
See Tantek’s comment below and his post on Open Social and Portability, as well as this O’Reilly Radar post from yesterday, which I just came across: “It’s the data, stupid.”
[/Update]

[Update2]
There is this text in the description of Hosting OpenSocial Apps:

To host OpenSocial apps, your website must support the SPI side of the OpenSocial APIs. Usually your SPI will connect to your own social network, so that an OpenSocial app added to your website automatically uses your site’s data. However, it is possible to use data from another social network as well, should you prefer. Soon, we will provide a development kit with documentation and code to better support OpenSocial websites, along with a sample sandbox which implements the OpenSocial SPI using in-memory storage.

(I added the bold). I guess we’ll have to wait to see just how data from “another” social network might be used, or even how data from many social networks might be used.
[/Update2]