Features of a federated social web

Yesterday I spoke about the federated social web – what its structure was and why people are interested.

But what will a federated social web do? We don't know, exactly: these kinds of systems tend to change when put into practical use. It took a while for email to handle file attachments reasonably well, and the HTML 5 process shows how much Web interfaces have changed over the last 15 years.

It's reasonable to assume that a federated social web will at least do what monolithic social networking applications do today. To that end, I've listed out some of the most important current features of social networks, generalizing a bit across different networks. I've then outlined where we are with federated social web protocols and software today: how close we're approximating monolithic social networks, and what we need to do next.

• Identity. Identity is your uniqueness. Your name may be John Smith of Cincinnati, OH, but you are distinct from every other John Smith in Cincinnati, past, present, and future. An important part of identity is addressability – having a machine readable address that computers and people can use to find you, and only you. Real people can have more than one identity in a social network (compare email, where many people have work and home addresses), but they're not typically linked in any way.

  Because identity is important for remote login and security, it's probably the best-discussed (maybe over-discussed) part of this system.

  There are competing schools of thought on identity and addressing. OpenID borrows the URL format from the Web: “http://evan.status.net/”. WebFinger, on the other hand, borrows the address format from email: “evan@status.net”. Whatever address format we use, it's likely to be hierarchical, with an organizational part (“status.net”) that belongs to the network you use, and an individual part (“evan”) that's unique within that network.

• Profile. Profile data is any information about you: your name, your avatar, postal address, phone number, favorite color, religion, political orientation, past jobs, education history, what kind of person you want to date, your favorite color, your favorite movies, your current bedside book. Almost all social networks provide a single profile Web page for individuals with all their profile data; some allow you to restrict sensitive data to only a subset of viewers.

  Profile pages fit in well with the way the Web currently works, and it's likely that the federated social web will include dedicated profile pages for each person. Sharing that data programmatically with other systems is less clear-cut; standards like FOAF, hCard and Portable Contacts give us a way to move the data between networks, but keeping it synchronized and up-to-date is hard.

  For privacy, it's easy to have one set of data shown to logged-in users while browsing and a more restrictive set shown to people who aren't logged in. But sharing some protected data with users in your social network that aren't on your server may be trickier. Remote login technologies like OpenID or OAuth might help here.

• Relationships. Declaring relationships to friends and colleagues is the lifeblood of any social network. Some networks allow you to define the nature of the relationship. Some require that both related people approve the relationship (“friends”), others one one (“fan” or “follow”). In either case, some or all people on the network can navigate your list of friends.

  Reading lists of friends or colleagues on the Web is easy. Restricting access to those lists has similar problems to the profile ones mentioned above. Machine-readable relationship formats is one of the best-developed features of federation, with FOAF and XFN leading the way. But actually establishing relationships is one of the least-developed. The “follow” model is used for OStatus; it basically says, “I'm interested enough in you to care about what you do and say.”

• Media. Sharing photos, audio, links, video and rich text with friends is a big part of social networks. Some networks specialize in only one medium like photos or video; others cover the spectrum. Sharing office files like word-processing documents and spreadsheets is important for corporate networks, too. Often, other users can comment on media, “fave” or “like” it, or reshare the media to their own social network.

  Navigating the media uploaded by another user isn't hard, but, as has come up before, there are some tricky parts with setting permissions based on relationships (“only for family and friends”). Delivering media remotely isn't well-specified; typically it's pushed as attachments for syndicated activities (see below), if at all. OEmbed can make the presentation easier.

  It's possible with OStatus to like, reshare, and comment on media (or, more precisely, the activities associated with the media), but this happens on the subscriber's server, and the response is pushed to the publisher's server. An interface to let remote users interact with media on the site that provides it is harder, although tools like OpenLike and OExchange may improve that.

  An important subset of this functionality is events; users can post events and others can RSVP for or against. There's a nice little event schema in ActivityStreams; we intend to fit it into the OStatus system in StatusNet.

• Activities. Most social networks show a timeline of activities by a user (“Evan posted a picture”, “Evan liked Michele's link”). Some provide an activity dashboard that shows activities by all the users' friends or colleagues. Human-edited status updates are an important part of this feed, with Twitter and other social messaging sites being an extreme example. As with media, downstream users can often “like”, comment on, or re-broadcast their friends' activities.

  This is where the most activity is happening today in the federated social web. Generating and sharing feeds, with RSS and Atom, is a forte of the open web. The latest development is ActivityStreams, which encodes machine readable information about social activities like posting a video or joining a group. PubSubHubbub is a real-time push protocol that cuts down on the polling typical of RSS feeds. Finally, the Salmon protocol lets subscribers push comments and other notifications “upstream” to the publishing server. OStatus has tied together all these protocols in a cohesive way.

• Messages. According to some sources, the volume of direct messages on social networking services rivals that of email. Private, direct messages are readable only by sender or recipient and can often have embedded media or links. Some services provide an empty message feature – a “poke” or “nudge”.

  This is a part of the federated social web that hasn't received enough attention. There is some work going ahead to implement remote private messaging using PubSubHubbub-enabled streams. Others have suggested that email has served this purpose for a few decades and doesn't need to be replaced.

• Groups. Grouping people together is an important part of most social networks. Users can join or quit a group (sometimes requiring the group owners' approval), send private messages to the group (which are distributed to all members), and upload images, video, or other media that “belong” to that group. Group admins can also announce events or provide a profile for the group.

  Most of the issues for individuals apply for groups, and the standards used for communications and relationships between individuals will largely work for groups. Joining a group is just establishing a relationship with it, for example. Similar issues with restricted browsing profile data and media. OStatus has explicit support for groups, although they're very simple.

• Search. Users on social networks can usually search for other people by name, location, interests, or profile information like age and gender. They can often restrict these searches to their own friends or friends-of-friends. On some social networks, it's possible to search for media or groups by keyword, with an emphasis or exclusive filter on your friends.

  It's unclear what part search will play in the federated social web. Making initial connections will depend on it (“Does 'Evan Prodromou' have a federated social Web profile?”), but usage may drop afterwards. There's a strong parallel with the email white pages and people search services of the 90s; these largely succumbed to general-purpose Web search engines. Media and groups that are publicly published will be accessible to Google and its ilk, but searching media that's available to the user, but not to Web crawlers, may be tougher to implement.

  In any event, it seems unlikely that social web search will require much in the way of protocols. Existing ping systems created for blogs, etc., will probably suffice, with search engines using crawlers to discover and share social web data.

• Client API. Some, but definitely not all, social networks provide a Web-based API that third-party developers can use to create desktop and mobile applications that access the network. Typical functionality includes establishing relationships, browsing an activity feed, and uploading or viewing media.

  Defining a standard client API that developers can use to access any social web site would significantly help uptake. However, there's been little work in this area so far. The Twitter API has become a defacto standard, and there is some work to use AtomPub to provide similar functionality.

• Data portability. This is one of the few features that is required for a federated social web that is not often implemented on existing social networks. Unfortunately, it's also not often implemented on software that aspires to federation, like StatusNet. Some possible contenders here are FOAF for the social graph plus SIOC for events, and ActivityStreams for a stream of events that could be “replayed”. Data portability may be the “killer app” of the federated social web, and it's going to be important to get it right.

We'll be discussing these and other issues in the federated social web at the summit on Sunday. One thing that's important to note is that we don't have to totally define each and every one of these elements before implementing others. Some things we think ahead of time are very important don't actually end up being useful or valuable in practice. I think that the framework we've put together in OStatus, for example, is an excellent first approach to federated social web systems.

Tomorrow, I'm going to talk strategy. What are the next steps we'll need to take to get the federated social web off the ground? What are the possible factors that will influence its adoption? Who are the important players? StatusNet is going to play an important part, but what else?