Implementing Open Social Web support on your site Joseph Smarr Chief Platform Architect, Plaxo

1. Implementing Open Social Web support on your site Joseph Smarr Chief Platform Architect, Plaxo Future of Web Apps Workshop, Miami, 2/28/2008

2. Agenda • 1. The emerging Social Web • 2. Building blocks for an Open Social Web • URLs as identifiers • OpenID • OAuth • Microformats • FOAF • MicroID • Social Graph API • OpenSocial • RSS / Atom • Friends-list portability • 3. Control and privacy issues • 4. A clear vision for the (near) future • 5. Q & A / Discussion

3. 1. The emerging Social Web • “Who you know” is becoming important for a large and rapidly growing number of apps… • …but finding who you know on a new site is still too hard • Current social networks are a glimmer of things to come when the web itself becomes social… • …and the building blocks for an open social web are already emerging and converging

4. 2. Building blocks for an open social web • URLs as identifiers • OpenID • OAuth • Microformats • FOAF • MicroID • Social Graph API • OpenSocial • RSS / Atom • Friends-list portability What it does Why you should use it How it works Who is using it Where to learn more

5. URLs as identifiers • What • Provides additional (safer) ways to identify yourself and find people you know from other sites • Why • Consolidate your identity (blogs, social network profiles, etc.) • Make it easier to find people you know • Avoid spam (URL has no inherent capabilities)

6. URLs as identifiers • How • Maintain lookup via profile / blog URL in addition to mailto:email or aim:screenname (xmpp:, skype:, …) • Let users maintain as many identifiers as they want • Verify identifiers using OpenID, rel=me (more later) • Can use hashed identifiers for lookup (and MicroID) • Who • Plaxo, Pownce, Digg, … • Where • http://epeus.blogspot.com/2008/01/urls-are-people-too.html

7. URLs as identifiers Plaxo: • Some of my identifiers • mailto:joseph@plaxo.com • http://josephsmarr.com • http://twitter.com/jsmarr • aim:josephsmarr • =josephsmarr Pownce:

8. OpenID • What • Protocol for proving you own a URL • Providers and consumers (“relying party”) • Why • Lower friction to sign up / sign in (no password, simple reg) • Enable trusted cross-site mashups • Conduit for data transfer (attribute exchange)

15. OpenID • How • Consumer and provider exchange shared secret • Consumer redirects to provider to log in • Provider logs user in and asks if they trust RP • Provider redirects to consumer with assertion • Consumer keeps mapping of OpenID(s)  user id • Who • Providers: Yahoo, AOL, Blogger, LiveJournal, MyOpenID, … • Consumers: Plaxo, Ma.gnolia, Blogger, O’reilly, … • Libraries available in most popular languages • Where • OpenID.net • Internet Identity Workshop • http://www.plaxo.com/api/openid_recipe

16. OAuth • What • Standard protocol for browser-based authorization to grant access to protected resources via token • Evolution of auth from flickr, yahoo, Google, etc. • Why • Let users access and share private info without taking passwords, scraping, or writing custom auth code • Quickly gaining momentum as the de facto standard

17. OAuth • How • Consumer and provider exchange app key and secret • Consumer redirects to provider to ask for authorization • Provider logs user in and asks to grant permission • Provider redirects to consumer with token • Consumer exchanges token for permanent token • Consumer passes token to API calls (or via auth header) • Plays well with OpenID (draft AX extension) • Who • Support planned by Google, Yahoo, AOL, Plaxo, Twitter, others • Some library support, still under rapid development • Where • OAuth.net / oauth google-group • Internet Identity Workshop

18. Microformats • What • Light-weight semantic markup that can be embedded directly in HTML to make info machine-readable • hCard: contact info • hResume: job history, etc. • XFN: links to friends, me-links • Why • Share and consume data from profile pages without needing a separate API • Very low overhead to produce • Assert linkages between online identities

19. joseph.myplaxo.com: to humans

20. joseph.myplaxo.com: view source <div> … <h1>Joseph Smarr</h1> <img src="http://images.plaxo.com/fetch_image?path=4294967299_0_418762113" /> … </div>

21. joseph.myplaxo.com: view source <div class="vcard"> … <h1 class="fn">Joseph Smarr</h1> <img class="photo" src="http://images.plaxo.com/fetch_image?path=4294967299_0_418762113" /> … </div>

22. joseph.myplaxo.com: to computers BEGIN:VCARD VERSION:3.0 PRODID:-//kaply.com//Operator 0.8//EN SOURCE:http://joseph.myplaxo.com/ UID:plaxo-4294967299-0 NAME:Joseph Smarr's Public Profile - Powered by Plaxo N;CHARSET=UTF-8:Smarr;Joseph;;; ORG;CHARSET=UTF-8:Plaxo, Inc. FN;CHARSET=UTF-8:Joseph Smarr TITLE;CHARSET=UTF-8:Joseph posted a blog entry BDAY:0000-02-14 PHOTO;VALUE=uri:http://images.plaxo.com/fetch_image?path=4294967299_0_418762113 URL:http://joseph.myplaxo.com URL:aim:goim?screenname=josephsmarr URL:skype:jsmarr?call URL:http://joseph.myplaxo.com/ EMAIL:joseph@plaxo.com EMAIL:jsmarr@plaxo.com ADR;CHARSET=UTF-8;TYPE=work:;;;;;; TEL;TYPE=work:650-254-5406 TEL;TYPE=cell:858-442-2353 TEL;TYPE=fax:650-254-1435 NOTE;CHARSET=UTF-8:As part of my ongoing work to help open up the social web, we've just released a full implementation of the new OpenSocial APIs in Plaxo Pulse! Exciting times are ahead! END:VCARD

23. Microformats • How • Standard CSS class names for common pieces of data • Embedded in DOM structure of web page (only maintain one copy, rich copy/paste, etc.) • Parse with tidy/xpath (soon: use Social Graph API) • Plug-ins available to view / use microformats (operator, tails) • Can “subscribe” to URL  check for updates, pull them down • Who • Lots of side produce them • Some sites consume: dopplr, satisfaction, plaxo, … • Open-source parsers, technorati proxy parser • Planned support in Firefox 3 • Where • Microformats.org

24. FOAF (“Friend-of-a-Friend”) • What • RDF spec for representing profile and friends-list info • Why • Easy way to make social graph data portable • Single file format for who I am and who I know • Data can be distributed across the web and joined together • How • Look for FOAF files and parse them • Can produce FOAF files for users and link to them from profiles • Who • LiveJournal, Hi5, Plaxo, PeopleAggregator, … • Where • foaf-project.org

25. MicroID • What • Hash of two identifiers to verify linkage / ownership • Why • Validate that a user owns a given profile page, or that two identifiers represent the same person • Broadcast validated linkages without leaking raw information • How • uri+uri:algo:hash, e.g. mailto+http:sha1:sha1( sha1(“mailto:joseph@plaxo.com”) + sha1(“http://joseph.myplaxo.com”)) = mailto+http:sha1:a70039016279cc5a7839e47fad2f8d597080a3a4 • Verify by computing hash and comparing • Publish in head of pages: <meta name=“microid” content=“…” /> • Who • ClaimID, Last.fm, Ma.gnolia, Wikitravel, Plaxo, … • Where • MicroID.org

26. Social Graph API • What • API to access public social data (XFN, FOAF, …) • Open-source library for canonicalizing profile URLs • Why • Quickly lookup public info for users build meta-profiles, find out what sites they use • How • Google already crawls the web parse it and make data available via JSON API • Can add fme=1 to get transitive closure of me-links • Can get back-links (who links to me?) • Only uses data in public web crawl • Who • Google (Brad Fitzpatrick), Plaxo, … • Intended to be copied by others • Where • http://code.google.com/apis/socialgraph/ • http://bradfitz.com/social-graph-problem/

27. Me on the web http://josephsmarr.com

29. Social Graph API • What • API to access public social data (XFN, FOAF, …) • Open-source library for canonicalizing profile URLs • Why • Quickly lookup public info for users build meta-profiles, find out what sites they use • How • Google already crawls the web parse it and make data available via JSON API • Can add fme=1 to get transitive closure of me-links • Can get back-links (who links to me?) • Only uses data in public web crawl • Who • Google (Brad Fitzpatrick), Plaxo, … • Intended to be copied by others • Where • http://code.google.com/apis/socialgraph/ • http://bradfitz.com/social-graph-problem/

30. OpenSocial • What • API spec for building “social gadgets” that live inside social networks and have access to profile, friends, and activity stream • Open-source “shindig” project for turning any site into an OpenSocial “container” • Will be supported by most major social networking sites • Why • Write-once, run everywhere  more distribution, less code • Containers: network effects of developers across all OpenSocial sites  don’t need to build a custom API and woo developers

31. OpenSocial

32. OpenSocial • How • JavaScript + HTML, lives in iframe, callback-style for accessing social data • Gadgets can live in profile box or full canvas page • Generating activity goes into sites’ activity stream • Support for custom extensions to data, surfaces • Planned support for server-to-server REST APIs • Who • MySpace, Orkut, Hi5, Bebo, LinkedIn, Plaxo, Ning, SixApart, … • Developers: Slide, RockYou, Flixster, iLike, Shelfari, … • Spec is at 0.7 now; still work in progress • Planned rollout in Q1/Q2 for many sites • Where • http://code.google.com/apis/opensocial • OpenSocial hackathons

33. RSS / Atom • What • Standard formats for syndicating user activity (not just for blogs!) • Why • Publish activity from your site so it shows up elsewhere  drives awareness and attention back to you • Subscribe to user activity from other sites  richer profiles • How • Publish: list most recent activities with title, description, etc. • Subscribe: periodically poll for updates; check for new items • RSS feeds can be private (obscure URL, OAuth, …) • Who • Tons of publishers, feed readers, Pulse, SixApart Action Stream • Where • Google for RSS or Atom

36. Friends-list portability • What • Recipe for finding who you know on a new site based on your existing relationships • User-centric, distributed approach to building and consuming social applications (“facebook-like platform for the web”) • Why • Lower friction to finding friends, drive engagement and retention • Social networks become a platform where relationships are leveraged instead of a dead-end; syndicate social app activity back

37. Friends-list portability • How • Let users maintain list of discoverable identifiers • Provide users with API access to their current friends list (can be protected, e.g. by OAuth) • Provide lookup API to find local members by identifiers • Users can pull in existing identifiers from one site and look up who they know on your site with the discovery API • Can be run persistently in the background  notified when new people join the site or you meet new people who use it • Who • Most sites support pieces of this  need to move to open standards (possible but hacky today) • Plaxo planning to release technology to make this easier • Where • http://blog.plaxo.com/archives/2007/12/a_practical_vis.html

38. 3. Control and privacy issues • Private vs. public info • Portable != public • Who owns your data? • Address book vs. social network? • Social contracts vs. technical restrictions • Discoverability (how findable am I?) • Maintaining multiple personas

39. 4. A clear vision for the (near) future • A user-centric Social Web with durable, portable identity • Social apps are easier to build and sccle because technology and user data are both readily available • Social apps can remain on independent web sites and/or as embedded gadgets in social networks • Users can control which sites have access to their data • Don’t need to start from scratch each time • Relationships become richer and more durable • Users will start to delegate responsibility for maintaining aspects of their social graph (business, family, etc.) • Users will maintain multiple personas (professional, personal) that stitch together info from multiple sites • Activity from social apps will be syndicated across other sites and drive attention and discovery back

40. 4. A clear vision for the (near) future • We’ve seen this movie before… • The pie is about to get a lot bigger  room for everyone to win

41. 5. Q & A / Discussion