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 14 - jetpack.people: Assembling and Applying 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 or the browser to get into social media and take charge of making interactions better for users. We also intend to take advantage of some recent research on modeling social relationships from social media data. We describe some jetpack.people application scenarios later in this document.

Proposal

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

Looking up a person

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 each site, e.g., FBUsername, TwitterUsername, etc.

email: An email address that might identify a person.

url: A url, like a personal website, that may identify someone.

name: First name, last name or both.

Alternatively, you can invoke the find</find> by passing it a filter function. Instead of passing keys, you pass a function that evaluates some condition based on jetpack.people.person metadata.

Arguments

filter( person ): Gets called as find iterates over the people in the social data store. It evaluates to true or false. If true, the person 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 a section below. If find does not locate anyone, null is returned.

Examples

An example of finding a person is as follows:

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

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