Labs/Jetpack/JEP/15

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

JEP 15 - jetpack.people: Assembling and Making Use of Social Data

• Champions: Eric Gilbert <egilber2 at cs dot uiuc dot edu> & Aza Raskin <aza at mozilla dot com>
• Status: Implementing
• Type: API Track
• Created: 11 Jun 2009
• Reference Implementation: None
• JEP Index

Introduction and Rationale

This JEP describes a store of social data for Jetpack. Part of this proposal calls for a jetpack.people namespace and a jetpack.collectors namespace in the Jetpack API.

One of the web's main functions is to mediate communication between people. According to Hitwise, mediating communication is the core business of 5 of the top 10 most-visited websites.

Now imagine a user who regularly visits three different social media sites: GMail (it's social and it mediates), Twitter and Facebook. The traces left behind at each site tell stories about the user's online relationships (e.g., email threads, @-discussions, RTs, wall posts, etc.). What if the browser could learn about them over time? What if it could do something smart with that knowledge? Some of the data will cross site lines, as some people live in both Facebook and GMail, or in all three simultaneously. The relationship (in the online sense) is the aggregate of all these sources. The browser is especially well-placed to understand these relationships. That's what we intend jetpack.people to do.

Clearly, we must ensure privacy. Yet, this can be accomplished in the same way as the browser protects browsing history. We see this as a particularly forward-looking proposal. We think it's time for the browser to get into social media and take charge of making user experience richer. To do this, we intend to take advantage of recent research inside jetpack.people that demonstrates how to model relationships based on social media data. We also describe a handful of jetpack.people application scenarios later in this document.

Proposal

jetpack.people will provide access to social data. jetpack.collectors will provide access to the underlying data collectors for various sites.

Looking up a person

You can look for a person in the store of social data in three ways: passing a name string; passing a dictionary of named keys; or, passing a function by which to filter people.

jetpack.people.find( name )

Arguments

username: The name ("firstname lastname") of the individual you are looking for.

jetpack.people.find( keys )

Arguments

keys: A dictionary containing key-value pairs username, email, url or name that might serve to identify a particular person (one or more must be specified).

username: An site-specific identifier. At some later point, it may make sense to break this out into identifiers for each site, e.g., FBUsername, TwitterUsername, etc.

email: An email address.

url: A url, like a personal website, which may help to identify someone.

name: First name, last name or both.

Alternatively, you can invoke find by passing it a filter function. Instead of passing keys, you pass a function that evaluates a condition based on person metadata.

jetpack.people.find( filter )

Arguments

filter( person ): A function that gets called as find iterates over the people in the social data store. It evaluates to true or false. If true, the person is included in the result set; if false, then the person is not included.

Return value

In the keys case, find returns a dictionary of key-value pairs representing a person. In the filter case, find returns an array of these dictionaries. The dictionary fields will be populated by collectors and will grow organically. We describe our initial person meta in the next section. If find does not locate anyone, null is returned.

Examples

An example of finding a person is as follows:

var person = jetpack.people.find({ "username" : "eegilbert" });
if( person )
  jetpack.notifications.show( person["durationOfRelationship"] );

var people = jetpack.people.find(function(person) { return person.isStrongTie; });
if ( people ) {
  for (var person in people ) {
    jetpack.notifications.show( person["fullName"] );
  }
}

Social data collectors

jetpack.collectors.gmail.on(); // on by default

Collectors form the backbone of any application taking advantage of social data. They will collect data passively as users visit sites (when installed and turned on). Each site (e.g., GMail) will require a collector, although common methods will be abstracted to a higher interface. In the initial implementation, we plan to build collectors that will populate person data from three sites, GMail, Twitter and Facebook. We will be as polite and respectful as possible when obtaining this data. If the site provides an API, we will make every attempt to use it. If not, only use data as it is rendered on a page at the user's request.

Person metadata (e.g., "durationOfRelationship") will grow organically as we explore what is most useful. We hope to make use of the new proposal for simple persistent storage. It will be a schema-less database in the early stages. We plan to keep track of the data collected about social contacts in a wiki article.

Usage scenarios

Imagine a loosely temporal Twitter feed. Most of the tweets occur in temporal order, but if a low-frequency important contact tweets, it sticks to the top of the page until you see it. "Important contact" here might be as simple as "you have each @-replied one another" or it might be a combination of many factors (we prototyped this above as "isStrongTie").

Or, imagine a GMail notifier (like the one in the Jetpack demo) that only notifies you when a thread you have actually participated in becomes active. Or perhaps a thread from a strong contact. These are the kinds of ideas we want to explore. The plan is to build a couple to demonstrate what is possible, but let developers explore other ideas on top of the platform.