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

2. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr URLs as identifiers Some of my identifiers  mailto:joseph@plaxo.com  http://josephsmarr.com  http://twitter.com/jsmarr  aim:josephsmarr  =josephsmarr Plaxo: Pownce:

8. Joseph Smarr 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)

9. Joseph Smarr

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. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr 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 Smarr joseph.myplaxo.com: to humans

20. Joseph Smarr joseph.myplaxo.com: view source … Joseph Smarr …

21. Joseph Smarr joseph.myplaxo.com: view source … Joseph Smarr …

22. Joseph Smarr 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 joseph.myplaxo.com: to computers

23. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr 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:a70039016279cc5a7839e47fa d2f8d597080a3a4  Verify by computing hash and comparing  Publish in head of pages: Who  ClaimID, Last.fm, Ma.gnolia, Wikitravel, Plaxo, … Where  MicroID.org

26. Joseph Smarr 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. Joseph Smarr Me on the web http://josephsmarr.com

28. Joseph Smarr

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. Joseph Smarr 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. Joseph Smarr OpenSocial

32. Joseph Smarr 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. Joseph Smarr 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

34. Joseph Smarr

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. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr 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. Joseph Smarr 5. Q & A / Discussion