Bridging the islands: Building fluid social experiences across websites

Social Web – John Panzer, Joseph Smarr

As more sites add social functionality, profiles, friends, and conversations are becoming increasingly fragmented and redundant. But an emerging collection of open technologies aim to help bridge these social islands, allowing users to seamlessly move between sites, bring their friends along, and have unified conversations that span multiple web sites. Come learn how OpenID, OAuth, Portable Contacts, ActivityStrea.ms, and Salmon can help you connect your site to the rest of the Social Web, increasing your traffic, engagement, and relevance to your users.

Session type: 201
Tags: OpenID, OAuth, Portable Contacts, ActivityStrea.ms, Salmon
Hashtag: #islandsio

Date: Wednesday May 19
Time: 3:00pm-4:00pm
Room: 9

Recapping Chris’s story ….

• “Kate” and “Jack” lived on 2 separate islands….
• Vacationed on same island (shows map of social media)
• Met and fell in love
• Had to leave old friends on their own islands
• Its really hard to visit other islands (when people try, they get stopped by the island guards)
• You have to fill out lots of forms before you get onto the islands (registration pages)
• Some islands get together to let islands move together (good for big islands, but not the smaller islands)
• So, some young islanders, geeks, came up with a solution that works for all island and everybody all the time
• WE all have an immigration problem on the social web
• Separate accounts, passwords, etc for each website
• Friction every time you sign up for a new services
• Lots of profiles that are out of date, cause too hard to change one by one
• Also poor security, when you reuse username and passwords
• Interactions are biased towards working with a few big services, so you don’t give your users a lot of choice
• Bad for developers and bad for users
• Good news, you can now let users sign up for a new services using their eisting accounts!
  • Solves two related problem who is this user, what data do they already have, supported by most major services today (increasingly based on open standards like openID and Oauth)
• How can we find out what services a user uses?
• Right now sites have lots of buttons for each type of account (e.g., Facebook, Twitter, etc)
• Clues, you can look at their email address, if its a gmail, you can offer google onboarding, etc.
• Better, you can use Webfinger where you can basically look up a person by their email address and the service will list all the services the user has
• Also, Xauth, where the browser tells you information, gives hint, like, someone on this computer is using Google, you might want to offer them google onboarding, etc.
• Demo
  • Gets email link to Plaxo
  • It goes there, since its from gmail, it offers onboarding with Gmail
  • Offers to grab info from gmail to get started (i.e., contacts)
• Xauth … even if doesn’t come from Gmail … xauth tells the page what service you use and if you are logged in … meebo demo.
• Xauth.org is where you can go to check what your browser is saying
• How do you build this?
• Doing the dance
  • browser redirect / popup to get user’s cconsent on the other site
  • Response contains user identifier and access tokens
• Store external identifiers linked to local use accountingStore access tokens with user to fetch external data
• With xauth there is a simple JavaScript site to add
• Back to the story … once the islanders set this up, they has a “passport system”
• Brings us to Chapter 2: Staying Connected
• At their own islands they were Jack and Kate.
• But on other islands, they needed a forwarding type system to get contact when not in their home island
• We need forwarding addresses on the social web as well …
• Increasingly you know people ways that are not email addresses (e.g., by twitter address)
• Also, you may want to control how you can be found
• Also, information in these websites seem to stay in these websites
• Fragmented messaging systems and social “inboxes” … and too hard to control how others contact you
• Bad for users and developers
• Good news
• You can let users link their profiles together and bring their friends with them!
• Make it easy for users to control how “findable” they are (let them link to their other profiles like rel=me, Social Graph API (Google crawls and gives you all of these so you don’t have to crawl); Look up their preferred services on other sites using webfinger; let them pull in their existing contacts / friends-lists via API’s)
• Supported by most major services
  • Micoformats, portable contacts, opensocial, etc. (open standards)
• What if users want to keep separate profiles / friends? That’s find, let them control their “discoverable identifies” Can use existing friends as suggestions, or auto-follow/friend…same goes for sharing content to/from users’ other sites
• Plumbing Demo
• Joseph Smarr’s google profile
• Shows his profiles linked to
• Its found different links from each of those profiles
• The full set of public websites he felt comfortable supporting
• Webfinger … email based, spilts out the following services … spilts out machine readable info of publically published data … JSON and XML
• Very quickly this gives you a rich tapestry of information about a user
• All using open standards
• Mechanical advice for this?
• Let users claim and verify multiple email addresses, urls, and accoutn profiles …. use Social Graph API (FME=1) and webfinder to xpand the list with existing public profile inks on the web … Use contacts using Oauth, etc…. (he talks fast)….
• All were happy….
• Chapter 3: Keeping in touch and Sharing
• To check to see whats going on on other islands, they have to go visit each of them
• Keep checking, not getting updates in real time
• At each island, they are doing complicated things, but the language they have is insignificant (i.e., text in bottle, email)
• They want it to happen automatically, as the natural course of things
• Solutions…
• Problem: staying in touch on the social web. Right now its RSS and Polling. Its a problem because its not scalable. The content that gets squeezed into it is turned into text messages, measning gets squeezed out. Slow, lots of wasted efforts polling, etc. When content does get going, it ends of being silo’d at other islands, and the island that created the content never find out about it.
• Bad for users, bad for developers, rain cloud….
• You can share and consume rich activity data in real-time
• Annotate your feeds with rich, glorious metadata (activitstrea.ms)
• Seperate verbs and objects for links, photos, reviews, etc.
• Better “echo cancellation” for re-synidcating content
• Ping a hub with updates and subscribe to streams PubSubHaubbub
• Make users activites and replies “swim upstream” Salmon
• Quick Demo
• www.cliqset.com
• (and Status.net is the other one that has implemented this)
• Its a microblogging site where you can write messages and mention other people
• Cool mouse over that webfinger helps generate without cliqset knowing of it
• Links to status.net, you can the messages are there two
• How did they do it?
• Providing Webfinger as starting point
• Using email identifiers, or urls, etc.
• WebFinger demo
• How did I find Kate … put in her email address, generates all the machien readable data that is public for her … one of them is her Salmon replies because she wants to know when people are talking about her … also published a “public key” for…
• Links and types are listed, you can include a lot or a little depending on how private you are …
• Producing activities … add verb and activity types … and use Cliqset’ “feed proxy” for many pre-AS feeds … map to existing verbs where possible, can augment with site-specfic verbs too … keep unstructured content as well for compatibility … use web finger … a few other things I missed …..
• Consuming activities … map it to your gui … prive rich ux baed on known semantics … display activty geneerator for attribution ….etc.
• Going rel-time: PubSubHubbub
  • So when that video is shared out, they can get it right away
  • ad <link rel=’hub’> to the feeds you produce …
  • POST a ping to yoru chose hub on changes
  • Run your own hug, or use an existing gone
  • missed a few things
• Being a Salmon Stream
  • For comments, add a <link rel=’salmon’> in feeds your produce
  • point at a salmon endpoint that accepts POSTS
  • Add a comment when you see a salmon
  • For mentions, similar …
• Sending Salmon Comments Upsteam
  • Look for link re=”salmon’ I feeds you consume, rember for later
  • When uers comment, POST the comment back to the Salmon endpoints
  • Sign comments via Salmo’s magic signtuare (publich public keys for users via webfinder)
  • Something else
  • Meant for public web for now ….
• Sending Salmon Mentions
  • When you see a mention, perform Webfinger discovery on the ID
  • If there’s a <rel ‘salmon’> link in the XRD, POST the mention there
• Salmon Activity Demo (helps combat abuse that comes with a distributed service with no central authority)
• End of story of the islanders.
• Joseph summary
• Every story needs a moral
• Problem visiting each other and traveling to other island (OpenID)
• Problem staying in touch distribute (WebFinger)
• Problem sharing rich content in real time (
• Concluding: using island metaphor a lot
• Great to have lots of different islands that can link to each other
• Google supports this, users win
• Having rich experience across sites, with big and small players getting involved, and how increasingly its done with Open Standards
• Lots of links here …

Q: As a salmon developer on the email list, when do you think it will be at a point where there will be libraries out there like OpenID, so we don’t have to understand all the details of the protocol …

A: Mentioned a few languages starting to offer this … working to collect them and make them open sourced … we plan on using these for our own deployments … none of these specs are too hard, build them and then open source it…