Tip:
Highlight text to annotate it
X
Smarr: I'm Joseph Smarr. I'm from Plaxo.
I'm really happy to be here.
This is my second Google I/O,
and no better way to sort of benchmark
how much progress we've made in the last year,
which is mainly what I want to share with you guys.
Please feel free to ask questions
throughout the session if you have.
There's microphones.
But I think if I time this right
there should be plenty of time at the end
for Q and A too, so I really hope if you have questions,
you'll get a chance to ask them.
And gonna try to do a lot of demos here.
I know the WiFi Internet's been a little bit flaky,
so demos in a live setting are always
a little bit masochistic to start with.
But hopefully that will all work
because I want you to see how much of this stuff
is really real and not just theoretical.
And this little link down here, if you can see is--
there's a Google Moderator apparently
that you can submit questions live as well
during this presentation.
So ISGDHJQS.
That's as merciful as I could make it
for transmission over the air.
So I thought I'd start by just briefly talking
about what I said last year to kind of contrast it
from where we are today.
So I gave a talk last year at Google I/O
called "OpenSocial, OpenID, and OAuth: Oh, My!"
And it was sort of starting to say,
hey, there's this groundswell
of interesting open technologies that are starting
to be developed that potentially could let you do
a lot of very interesting things with connecting up
different websites together and not having
to start over from scratch on every site that you go to.
And the real question, I think, back then was:
Where is this all going?
Which of these technologies are complementary
or competitive and who's gonna actually use them?
And what are users gonna have to learn?
What are technologists gonna have to learn?
And the picture I sort of floated
was that I said I think what's gonna happen
is there's gonna become a set of kind of service providers
in the middle that act on behalf of the user
out to all the websites across the web
that want to be social.
And there'll be sites that want to act
as your identity provider so, you know--
okay, I've already got an account.
And I said there would be sites
that would want to act as your social graph provider.
So I've already got an address book or a friends list.
I don't want to have to recreate that everywhere I go.
And that there would be sites that would act
as content aggregators that would be able
to let you see the activity from you and your friends
all over the web, and that these would create
kind of a symbiotic ecosystem that made it a lot easier
for new sites to come up and be social
and let users come and find those sites.
And then in particular this would enable kind of
a virtuous cycle where if it's really easy for me
to go check out some new site
because I don't have to sign up and put in a new password
and fill out a new profile and upload a photo
and all that stuff,
and if it's really easy to bring in
my existing social graph and find out who I know
on that site--maybe it's a niche site
that not everyone I know is going to be interested in
but a few people are--
then I can start to have an experience there right away,
and it lowers that barrier to trying something new.
And if then when I do create some activity there,
I make a review or I author some content or what have you,
if that can flow back out into my aggregator
and all my other friends who aren't part of that site
can see it, they not only learn about what I'm doing
but they learn about the site.
And if they can then go and do it themselves,
you can see there's this really nice, virtuous cycle,
at least in theory, that should allow lots
of new websites to grow and quickly flourish
by reducing a lot of friction all around.
And then later that year, it became clear that while each
of those individual pieces was useful, there was something
really magical about putting them all together.
And that the-- sort of being both the way
that I can go into the website and bring my identity
and my contacts and pull information back,
that there was sort of a whole
that was more than the sum of its parts.
And that was also reflected in the technology.
There were all these independent projects
that were started for very different reasons
but all sort of started to come together
into what we sort of loosely called the Open Stack.
And that a term that sort of people seemed to latch on to.
'Cause it was like, yeah, there's a bunch of stuff here
where it's not individual companies just with platforms.
It's really a set of technologies,
kind of like a set of protocols like the web itself.
It was gonna allow all this creativity to happen
in the social dimension.
And so it's interesting to go back and say,
"Okay, that was last year.
What's happened since then?"
And I'm sure if you guys if you guys
have been paying attention at all,
you've seen there's just a flurry.
Yahoo's whole YOS strategy is completely based on this.
Windows Live is now a sort of aggregator
and--take your information around.
Google, Yahoo, Microsoft, AOL-- the list goes on,
all being OpenID providers for all of their users.
And on and on.
And then Facebook, right? Facebook Connect.
Very much this same model.
Not exactly the same technology under the hood,
but exactly the same concepts.
MySpace, same thing.
MySpace ID-- like Facebook Connect,
but in fact all the Open Stack under the hood.
And then most recently,
Facebook getting involved in OpenID as well.
So even bringing the Open Stack around to everybody.
So just a real flurry of activity.
Google supporting portable contacts recently too.
And of course FriendConnect being this thing
that allows you to take that information out
to any website and immediately drop it in.
So the little guys actually have an advantage
over the big guys a lot of times.
And as that was all happening,
all of these trends were just having great success.
So this is, you know, JanRain tracks the number
of unique relying parties of sites you can go using OpenID
and it just continues to go up and up and up.
There's a Wiki that tries to keep track
of all the different sites that have OAuth enabled APIs,
so ways to access your private data without having
to give away your password in a standard way.
And as you can see I can't even fit the list
on the screen anymore.
This is a snapshot of some of the feeds
that you can share into Plaxo Pulse,
sort of one of the first web-wide aggregators.
And again, not only has the number of places
that have feeds really expanded,
but the number of really mainstream sites.
You can get your Netflix reviews.
You can get the stories you think are interesting
on "The New York Times."
There's all this sort of stuff that you can do
that is really interesting to real mainstream users
as well as all the early web 2.0 stuff
that pioneered this.
And OpenSocial, I mean, what a radical concept.
OpenSocial only started publicly
a few months before last year's Google I/O talk.
And not only did they get all of these different big sites
as a community to come together to say,
"Yes, let's have a standard platform
"for building these social applications.
Let's not have the browser wars but worse."
It's now deployed on enough sites
that, collectively speaking, it's hitting
hundreds and hundreds of millions of users.
So again, very mainstream adoption
in a very short period of time of these new technologies.
Just to me, that-- really extraordinary
to watch that pace of innovation.
So when I take that all together,
seems very clear to me, and I hope it's clear to you,
that the whole web is going social
and the social web is going open.
And that's a pretty fundamental transformation.
In fact, a lot of people, I think,
feel that it's as fundamental as the birth of the web itself--
where you had this sort of new paradigm,
this new ecosystem that was gonna foster
just an absolutely rapid amount of innovation
because the protocols themselves
were fundamentally open to anybody with a good idea
to come in and play.
And so there's a lot of things you can now do
to take advantage of that.
And so I want to show you throughout most of this talk
is all the things you can actually go do today
and that people are doing to start to live
in this new social ecosystem.
Because even though this has been happening so rapidly,
or maybe because it's been happening so rapidly,
I think a lot of people haven't really woken up
to just how much of the stuff is actually real,
how much of it is actually suitable for mainstream users,
and how powerful it can be for your applications.
And so four things I want to just sort of focus on
is areas that can add value to your services right now.
One is how to streamline your sign-up flow.
So how to make it easy for new people to come
and find out your app without having to create
yet another account, another password, another profile,
photo, on and on and on.
Putting and end to what we call refriend madness,
which is not having to refriend the same person
everywhere you go.
So you can say, "Yes, I've already made friends here.
Let me use that existing friends list on this new site."
Getting rid of the password anti-pattern,
which is where sites ask you for your password
to another service in order to access data
on your behalf, right?
That's obviously sort of scary
from a security and privacy perspective.
And scraping is also, technically speaking,
kind of ugly and breaks a lot.
But until there were good robust APIs and standards,
there often wasn't an alternative for doing
real deep integrations.
And so now we're finally getting to the point
where the safe and secure way is actually better
than the insecure way.
And then finally, what I call
"riding that virtuous cycle of social discovery."
So being able to actually have your app go through
that loop where more people can discover it and share it
with their friends, and they can come find it and so forth.
And so I thought rather than just talking,
I would try to show you as many demos of this
in the wild as I could,
and then sort of talk through what's actually going on
under the hood so you'll get a sense of sort
of what this really means and hopefully be fodder
for some more detailed Q and A.
And I invite you to go as high level
or low level technical as you like.
This is what I do for a living and I love it, so...
The first thing I thought I would start with
is something--and most of these
I've demoed at one time or another before.
There's nothing that you'll probably hear or see
for the first time, but if you're like most people,
it's hard enough to keep track of all these things.
So hopefully everyone will see something
sort of new and interesting here.
The first one is an integration that we did with Google
using a hybrid of the OpenID and OAuth protocols
for an easy way for Google users to sign up for Plaxo.
But it would work with anybody that supported these standards.
So let me jump over to my trusty web browser.
Okay, so here I am.
I'm Hong and my friend Joseph has invited me to join Plaxo.
This is like any initiation email
you get to any social service.
But what's interesting, when I click on it
to go sign up-- well, gosh darn it.
It's already starting to do this thing here.
Let me quickly go in and see if I can regenerate this.
As I say, live demos are always a little bit masochistic.
Hold a second.
I'll have to also see how flaky the Internet is or not.
Let me try sending this guy another invite.
All right.
I think probably I tested this invite before.
Okay, so here's a shiny new invite.
I've already signed out--yeah.
Okay, so like a normal invite,
but because the user came from Gmail,
we were able to recognize that, oh, you know,
there's a better way to sign up with your Google account.
Sign up in just a few clicks.
And so we're able to give the person a custom landing page.
And if the user wants to,
the can go through our normal sign-up flow.
But if they click the sign-up with my Google account button,
we actually take them over to Google
and we say, "Hey, we'd like some information
from you to get started."
And the cool thing is we were able
to tell that they were a Google user
because they got invited to a gmail.com address.
And they're actually already logged into Google
because they just came from Gmail, right?
So it's a very smooth experience.
And you can see it says, "Plaxo is asking for some information
"about this user.
"They'd like your name and email address,
"the language you speak,
and access to your address book."
And with one click, I can say "Okay, sounds good."
You're now taken back to Plaxo
and behind the scenes we create an account for you
that's tied to your Google account, so there's no need
for you to create a Plaxo-specific password.
And as long as you're signed in to Google,
you'll be able to stay signed into Plaxo.
And so the first thing I can do
when I get into the app, rather than having
to get another sign-up form,
is I can just answer that invitation.
So I can say--in Plaxo you can connect to people separately
as family, friend, and business,
and share different things with those different people.
So in this case I'm going to be his friend.
And then normally the next step we would take you to
is well, let's import your address book.
Do you use Google, Yahoo?
The standard thing you've seen a zillion times.
But here, because again we know that they're Google,
and they already gave us access to their address book
on that previous step, we can just immediately say,
"Okay, well, gee, let's go see which of your Google friends
use Plaxo here."
And so we can pull in their address book
and match it up against the list of Plaxo users.
And again, the next thing that they actually see
that they can do is-- here's a bunch of people
that you know that you can start to connect with.
Right? So just a very quick interface.
I'm not typing anything. I'm just clicking through.
And I'm immediately doing what I want to do
which is starting to use the app.
So and this goes on through.
I guess the last thing to sort of show you
that's sort of cool about this,
the standard connect invite, et cetera.
Connect to friends of friends, et cetera.
And get some basic extra information.
And when we land--the person gets landed in the app,
we show them this little thing that says,
hey, next time you come back to Plaxo,
you can just click sign in with a Google account
and you won't have to type in a Plaxo password.
It'll just remember.
If you're not signed into Google currently,
it'll make you sign in.
But if you are signed into Google,
it'll just be magic.
And in fact, if you come back to Plaxo
and you're already signed into Gmail,
you just will be signed in.
You know, any site will tell you that not only
is getting users to sign up and get through
that whole sign-up process-- you get a lot of drop off
and a lot of friction there,
but lost passwords are a huge problem
for any consumer service.
You haven't logged in in a while
and you don't remember what your password is.
Well, we get rid of all of that
because you're always gonna be signed in
to Gmail if you're a Gmail user.
So that's a good example.
And this is something we went live with
just a couple of months ago.
And so under the hood, again,
so what's happening is because it's been sent
to a Gmail.com address, we realize, oh, okay,
that's a Google user.
That's likely to be someone who could log in
with a Google OpenID.
And when we send them over,
one of the things you could do
when you're asking for somebody to log in with OpenID--which,
again, if you're not familiar with that basic concept,
it's like, I've already got an account over on Google.
I just want to have Google prove to Plaxo
that yes, this really is that user.
And then it can trust that--okay, well, in that case,
I'll make an account based on that credential.
It's just in this case my sort of Google URL as you will,
my own user URL.
But you can ask for additional data
to come across with that transaction.
So instead of just saying,
"Yes, this really is Joseph at Gmail,"
it can also say, "By the way,
can you give me some basic profile data?"
In this case, also, "Hey, could you give me
an OAuth token to access their address book?"
So OAuth by itself is this nice protocol
where similarly you can sort of bounce the person over
to a site and say, "Hey, could you give this person access
to some of your data?"
But you don't have to give away your password.
You don't have to give away all the rights to your data.
You can just give away a piece.
Like, maybe they can access my address book
but not my calendar, or they can read
to it but not write to it.
And so I can ask for that OAuth token
as part of the OpenID round trip.
That's the so-called hybrid piece of it,
'cause it's sort of combining them together into one step.
And so the nice thing is that the user
then literally just has to push that one button,
and all of a sudden we get, you know,
the fact that they're a Google user.
We get the verified email address,
so no need to send them that email
and say, "Hey, could you click on this
and prove you really are?"
Because obviously Google's the authority for Gmail.com,
so if they tell us that's the right user,
we have to trust them.
And we get the address book to be able
to start doing the import.
So really just cutting friction down.
And like I said, portable contacts
is the standard way of using OAuth
to get access to address book data,
which Google also supports.
And so what's neat about this is we actually
didn't write a line of Google specific code to do this.
It's just that Google was first out
with all of this implementation on their side.
So that's how it works.
Now you could ask the question, of course--
so is this actually something that moves the needle
on a consumer service?
Well, we're a very empirical company,
like I'm sure most startups these days have to be.
And so we see that when given the choice
to sign up with your Google account versus
signing up with a regular account,
people choose that predominantly.
And the completion rate of saying,
"Yes, I'm gonna sign up with a Google account,"
versus abandoning if you just show the person
the normal sign-up form is considerably lower.
So it starts out better but then it really gets going.
So of the users we send off to Google,
there's always this worry that you're gonna send them off
to some other website and they'll never come back.
Well, because you're already signed into Google,
you've been conditioned by the landing page
to understand you're gonna go sign in to Google,
so you're not jarred by it.
It's a friendly page that shows the little
Plaxo and Google logos together.
It says what you're giving out.
Like, it's not scary. It's very sensible.
So a whopping 92% of people that we send off
click and come back.
That's an astoundingly high figure.
Getting 92% of people to follow anything
even on your site is hard, right?
And so what that means is that far from this becoming
the chasm of death where you lose the person,
we actually get people to come back in droves.
And then, of course, they import much more successfully
because we don't have to ask them for a password
or remember what service they use or all that kind of stuff.
The contacts just come over.
And so, as a result, because they've got more data
and they're less fatigued, they end up doing
a lot more connection and invitation
and filling out data and all that good stuff
you want your users to do
than a comparable user who came through the normal flow.
So it just moves all of the metrics across.
And the cool thing is that they even come back more often.
Because even though they have to do this sign in
with your Google account, which is a little bit different
than what they're used to,
they're just signed in most of the time
'cause they're already signed in to Google.
Or if they're not,
they definitely remember their Google password
even if they don't remember their Plaxo one normally.
So we actually get better return visits as well.
And so the funny thing is we originally did this
as an experiment just to kind of test
how far we'd come along.
And once we saw how good the results are,
the business guys at Plaxo
wouldn't let us shut the experiment down.
'Cause they were like, "No, no, no, no, no."
We're like, "Well, we want to try some different things."
This is great, you know?
So it's actually now 100% of people who get invited
to add Gmail.com addresses now go through this flow.
And it's doing great things for us,
and the users love it, and Google uses it, right?
Loves it 'cause we're not scraping them.
We're not being insecure.
And the Google user now gets more value
out of having a good Google account,
a good address book up to date.
So I hope that's a good kind of concrete example
of how this interoperability based on these open standards
can really be effective and also be really user friendly
as opposed to some of the--
if you played with it maybe a year ago,
a lot of it was still sort of geeky and confusing.
But with this number of mainstream companies
really working on it now, the user experience
is something that's very rapidly improving.
Okay, so that's...
Oh, and then the thing I alluded to earlier
that's extra cool is because this is all based
on open standards and this was not a, like,
Plaxo/Google cabal,
anybody else who supports this, it works.
So MySpace also supports the hybrid OpenID
OAuth log-in and portable contacts.
And so I literally took this code
and pointed it at MySpace once they told me it was ready
and it just worked the first time.
That's pretty miraculous when you think about it.
The idea that the marginal cost
of implementing with a new site could be that small
means that we're much more likely to work with
a lot more sites and a lot smaller sites
because that barrier of is the *** for the buck
of integrating specifically with a big site
like MySpace or a small, more niche site
completely changes that equation.
And Plaxo's not the only one doing this now.
So if you--FriendFeed is another sort of real time
aggregation kind of service.
And if you go to their homepage now,
you'll see that they have these, you know,
sign up and find your friends with one click.
Technically it's two clicks.
We call it two-click sign-up.
They call it one-click sign-up.
It's a marketing thing, I guess.
With Facebook and in Google and in Twitter.
So what's nice is that other people
are playing both sides of the roles, right?
MySpace and Google swap out of Plaxo and FriendFeed
and FriendFeed could do MySpace too.
So it's all-- works out of the box.
And then, I guess, the one more thing there
is if you saw last week, Facebook's now doing this too.
So Facebook started testing OpenID support
on Facebook where, among other things,
they work with this Google flow.
So you can sign up for a Facebook account
really easily and then you'll stay logged
into Facebook if you're logged into your Google account.
So really impressive to see how mainstream
this is becoming.
And it's just unequivocally good for everybody.
It's a classic case of just removing inefficiency
from the system and everybody wins.
And so I thought to sort of pair with this,
I'd show you a MySpace version of it too
so you can start to see the pattern here.
And like I said, if you have questions
as you come along or-- I know I talk a little bit fast.
I get kind of excited about what I'm saying,
so please feel free to jump in at any time.
Okay, so here's a little demo site called 8-Bit Music.
And the idea is it's a niche social site
for people who really like the video game soundtracks.
You know, the little, like, MIDI, "Do do do do."
That kind of stuff, right?
And so it's the kind of site that won't appeal to everyone,
but there's a loyal subset of people
that would think this is really cool.
But it's exactly the kind of site
where it's like, oh, man.
I got to sign up for yet another account
and fill out yet another profile and find all my friends.
It might be hard for a site like that to thrive
in a world where everybody had to do all that from scratch.
But instead they've got this nice log in with MySpace button.
And so it just pops up again.
They do it with a pop up,
so not even taking you away from the page,
a sort of very friendly thing.
And, you know, if I weren't signed in to MySpace
it would ask me for my log-in and password.
But it's a MySpace.com URL,
so 8-Bit Music never sees my password.
And in this case I'm already logged in,
so it's just as easy to say, "Yes, this is me."
And you can see it's got that same friendly UI
where it's got the 8-Bit Music logo and the MySpace logo
so I can see what's going on.
And as soon as I continue, then again they get--
It's hybrid OpenID and OAuth and so boom, I'm in the site.
Here's my name, here's my photo, here's all my information,
and I can start to find people and share things.
So it's just really, really easy to start doing this.
And that really increases the chances
for small sites like this to grow and thrive.
And that's 8bitmusic.jdavid.net
if you want to play with that demo yourself.
I should mention all of these slides--
I think Google I/O is going to put them up,
but I'll also have them up on my website
which is josephsmarr.com.
And so I'll put it up when this talk is over
so you guys can get a copy that way.
And I'm also jsmarr on Twitter if you want
tweet out or follow or whatever.
It should be easy to get ahold of me.
Okay, so that was about--
how do you streamline the sign-up process?
And that's very important.
But there's still the problem of now do I want to--
I could import my address book,
but am I still friending each person again on each site?
And it's obviously the case
that you don't necessarily want everyone you know
to follow you around on every site you go to.
Like, I have different spheres of my life.
Everybody else does too.
And it's partly a privacy thing
but it's also partly just a signal annoyance thing, right?
I don't want to bug all of my colleagues
that I'd normally talk about OpenID stuff with
with my personal hobbies
that they may not be interested in.
And so you basically would like to be able
to have a situation where you can say--
in some cases, if it's a friendly site,
maybe I want to say well, gee,
if we're already friends on Facebook,
why don't we just have that be a transitive thing?
We can be friends here as well
and in other cases be able to just pick a subset.
And until recently that really hasn't been possible.
But we did a pretty substantial integration
with Facebook Connect recently where I think we started to--
sort of changed that a little bit.
So let's go back to-- let's see here.
Let's go back to that site.
Here I am, and I just joined with this account
that I created from my Google I'm importing.
So now let me go into my Facebook.
And I'll say okay, well, maybe I can connect with Facebook.
And I said let me not only see which of my friends use it
but I can share content back and forth between the two sites.
And so again, nice little pop-up.
In this case you can see it's not even a pop-up.
It's a little AJAX Lightbox,
because we've got some Facebook JavaScript on my page
and they've got a little hidden iFrame over
to their site so they can tell
I'm currently logged in to Facebook.
And so there's no need to actually pop up
a physical pop-up with a separate domain
'cause they're not taking any credentials.
So it can be an even more streamlined experience.
It's interesting, you know, the full page,
to the pop-up, to the now the--in line.
And again, same thing, right?
I hope you're getting a pattern here.
Plaxo and Facebook-- do you want
to share information, yes or no?
So it's a pattern I think the users
are gonna be able to learn and apply
across different websites.
And so when I connect, now Plaxo says,
"Okay, so now you tell me how you want to use
your Plaxo and Facebook accounts together,"
because some people want it differently.
So the first one says, "Automatically connect me
with my Facebook friends who also use Plaxo."
So that's this case that says,
hey, if we're already friends on Plaxo--
sorry, if we're already friends on Facebook
and we both have connected our Facebook and Plaxo accounts,
don't make us reconnect.
Let's just, you know, that's good enough.
We already said we were friends.
And if you don't like that, don't choose it.
But a lot of people find that to be very convenient.
And then it says-- do you want to share things
back and forth between the two sites?
And so when you go to do that,
because it's a deeper level of integration,
Facebook says, "Well, let me make sure
the user really wants this."
So they ask for a couple of extra permissions.
And this is a nice sort of model where
rather than having to give the user
ten check boxes up front,
you sort of wait for the user to interact
with the app and, as necessary,
you can escalate the amount of control that they have
so that it's really easy to get started
but you don't end up giving away the farm too early.
So this first says make sure--
is it okay if Plaxo knows who I am,
not just for now but ongoing so they can sync things
in the background and what have you?
Okay, sure.
And then the second one says, is it okay
if you can take the things you're sharing in Facebook
and also share that with my friends over on Plaxo?
And you can see again, it's a very nice visual representation.
This is actually, this says,
"Getting ready to demo it at Google I/O."
You can't see it but it's the real data that I've had.
So it's very easy for me to tell
what I'm getting myself into.
And so when I allow that, then it goes, okay.
So the permission's been saved
and so, here, let me go and set this all up together...
and wait for the Internet which has been
pretty cooperative but not the fastest.
Wait for it.
Yay!
So now my settings have been saved.
And if I go back to my homepage now...
Skip the opportunity to expand my network since I just did.
You'll see that now I've not only connected
my Facebook account but you can see I'm now connected
to four more people.
So these were all people who were my friends
over on Facebook and I'll apologize for the names.
These are all sort of test accounts.
But conceptually, these are four of my Facebook friends
who I may not have realized were even on Plaxo,
but because we all connected our accounts like this
now we're friends on Plaxo too.
And I didn't have to go through the work
of bugging them each time.
"Hey, do you also want to be friends on Plaxo?"
Because they all said, "Yes, I'm cool with that."
And so again the result is I start to get content here.
So here's a friend-- my friend Anita
shared some photos on Facebook, and they're coming across
and I'm seeing them in Plaxo.
And here's a video that they shared and I can play it.
If I want to watch it it takes me right over to Facebook.
So it's a very nice, tight interaction between the two.
Yeah?
The question is is the content replicated in each site?
The raw content's not.
So you can see here I'm actually over on Facebook.
So it's more like sort of the feed
of the information comes across.
But we watch it every so often, so if it changes
we can change it on our side as well.
So if you decide to make something private,
then it goes away everywhere else.
But it allows you to see it even where you're not there.
So that's another example of how, again,
any website not only has a hard time
getting users to start signing up,
they have an even harder time
getting them build to build that--a rich social graph.
And this makes it a lot easier.
And you may have seen, since this went live,
it also went--
Digg did a somewhat similar integration
where you sort of automatically follow all of your--
the subset of your Facebook users who are also Digg users.
And so that to me was a really cool example
because I always used to tell people, you know,
isn't it weird that here I am
in the middle of Silicon Valley, and everyone I know uses Digg
but I have, like, three friends on Digg,
and so I don't see what any of those people are Digging
because it's just too much work
to, like, go through and build yet another curated friends list
just on Digg, right?
But if it can happen automatically
through a site like Facebook that I've already gone
and built up a set of-- social graph,
now it's actually a much richer experience
when I go to Digg.
It's not just kind of what random 13-year-olds
across the world thought was a cool story.
It's what the people I actually know and care about
thought was a cool story,
which is a much more interesting, filtered view.
And so that whole being able to lower the friction
of getting that data to move
all of a sudden means that you can get
a lot more engaging experiences
and get your users into a much happier state
without having to make them do so much work.
So that's really the payoff here.
And so again, on the backend,
this really wasn't too hard to do.
So essentially what we have to do is
when somebody connects their Facebook account
and Plaxo account, we just have a little database table
that stores a mapping between their Facebook ID
and their Plaxo ID.
And then we store the little session key they give us,
which is kind of like an OAuth token
that allows us to make API calls on the person's behalf.
And then we can pull down their friends list,
which is essentially just a list of other Facebook IDs.
And we can intersect that with our mapping table
and see which of the subset of your Facebook friends
have also connected their accounts, and that's the set
of Plaxo users that we can auto connect you to.
And we just check the preference
to see if both sides said "Yes, auto connect me."
And if so, we do.
And we also-- I didn't show you this,
but you get a little notification in Plaxo,
like, if somebody comments on one of your photos or whatever
about each person that you've connected with.
So if you decide, oh, gee, I'm friends
with that person on Facebook
but I'm not really sure I want to be their friend on Plaxo,
you can just go in right there and change it
to business instead of friend
or get rid of it or whatever.
You're never surprised by what's happening.
It's very seamless.
And for most people most of the time
they're pretty cool with keeping the friends list the same.
But it allows you to kind of curate it on the fly.
And then what we do is we basically have
a demon that runs in the background every--
whatever it is, few hours, that checks, you know,
hey, do you have any new friends on Facebook?
Well, let's see if they're Plaxo members.
Or have you unfriended anybody on Facebook?
Have some of your friends since connected
their Plaxo and Facebook accounts?
And so it just runs in the background
and does that algorithm over and over again.
And so the cool thing is as more and more people
hook up their accounts I just get friended to them.
And as more and more people join Facebook
I get connected to them.
And so the benefit to me as a user
and also the benefit to Plaxo is not just
a one time thing like when you do a one time import.
It actually keeps getting better over time.
And so you get a marginal return
for that one time investment.
And so that's a really powerful model because
especially if you think about new sites that are small,
you may come as an early adopter and try to use it
and not find a lot of your friends there.
But over time a bunch more people are gonna join
and you'd really like that to be able
to bring you back to the site
and give you more reasons to keep interacting
with it and so now you can.
And then Facebook has this open stream API
which is another use of Facebook using open standards.
They've really gotten on the bandwagon
which is so awesome.
So there's another building block which wasn't even
in that Open Stack diagram from last year
called activity streams which is a sort of
a standard way of doing rich metadata
around shared a video or posted a photo or what have you.
And so we can-- it's a protected feed
but we got the access from the user,
that second permission dialogue you saw,
so we can suck that out and then share it privately
with the user's Plaxo friends.
And I think what's crucial there
is that--notice that I didn't have to make the data public
just to make it portable, right?
So I'm specifically wanting to share
nonpublic things with my friends and family.
It's just that some of them
are on Facebook and some of them are on Plaxo.
And I don't really want to have to make
all of my Facebook friends join Plaxo
or all of my Plaxo friends join Facebook.
I just want to be able to put stuff up
and share it to friends in both places.
I just don't want to have to make it public
to share it with everybody.
And with this sort of secure data portability
you really can do that.
And so that's a really powerful thing
that, you know, a lot of the success of early web 2.0
came from just getting around all these
tricky identity and privacy problems
by making everything public.
But that's not really what most people want
when you think about it.
And so now you don't have to do that.
Okay, and then presumably
you've been seeing this all along.
But you never saw me type a password in once, right?
And that's really cool especially when
you're using a tablet PC because handwriting recognition
for passwords is pretty bad.
It doesn't really look like an English word.
And so I wanted to show you an example on FriendFeed's site.
I think they've done a particularly good job.
They've got, uh, this-- you know,
Like all these sites, they have a little friend finder.
But rather than asking for passwords everywhere,
they've got this nice streamlined interface
where it just takes you over to the other site
and then shows you the people you might want to connect with.
So you can see here they've got Facebook, Twitter,
Gmail, Yahoo, and Hotmail.
And some of these are using open standards
and some of them aren't,
but to the user it all kind of works the same.
And hopefully over time as more and more people support
these open standards it'll be less and less work
for sites like FriendFeed to support
and they'll be able to support more and more additional sites.
But conceptually if I go to--let's do Yahoo this time.
So Yahoo makes me log in each time
because they're a little bit more paranoid.
Probably for a good reason.
And then they show me a bit of a scarier page,
but it's the same thing.
It's like, hey, is it okay
if FriendFeed has access to your information?
But then once I bounce back it's the same thing.
It's OAuth and boom. You can see how fast it is.
Here's a bunch of my Yahoo contacts
that I might want to follow on FriendFeed.
Now if instead I decide let's use Gmail,
it's the same thing, right?
So it's just very seamless.
It's actually a lot nicer
than having to type passwords in because I happen
to already be logged into those other sites.
If you're taking passwords, you don't get the value
of the person already being logged in
whereas here you do.
And they do Facebook as well.
And even Facebook has their own kind of--
It's not OAuth. It's their own version.
But it's conceptually very similar, right?
Yeah, yeah, so the fact that those other sites
aren't asking me for passwords is because I happen to already
be logged into them,
and if I weren't logged in I would have to log in.
But at least I'm giving my password only
to the sites that have my data
and I'm never giving a password to FriendFeed in either case.
Right? Does that make sense?
So that's a lot more secure for me
because if I don't trust FriendFeed
then I can always say they can't have access later.
And I don't have to go change my password,
and FriendFeed can't go and do anything
other than read my address book.
They can't go in and delete my account or whatever
which any site you give your password to
theoretically could.
So you really have to trust them.
So this is a cool example.
I just wanted you to see also that it's not just Plaxo.
We've obviously been very eager early adopters
and evangelists of a lot of these open standards
because our service is all about helping you
stay in touch with people across
all the different services you use.
But lots and lots of other sites are starting
to use these technologies
and having great success with them.
And I think FriendFeed's implementation here
is fantastic.
And so behind the scenes one of the things
that's helping a lot here is that even though
a lot of these sites standardized on OAuth
for being able to give access to data
without your password,
they still all have their own contacts API.
So Google had Gdata contacts
and Yahoo had the Yahoo address book API
and Microsoft has Windows Live contacts and whatever.
And so even though you could just use
the code once to get access to the data,
you still had to write separate site-specific code.
And really to have the kind of virtuous cycle
we're talking about, you really want
to have the protocols themselves be open standards
so that you can talk to someone you've never heard of before.
So if you're a small site,
you don't want to have to convince FriendFeed
to add an importer for your site.
You just want the user to be able to say,
"Hey, I'm on this small site
but we speak the same standard so it just works."
And so portable contacts is a standard that does that.
And it's basically just a very simple RESTful API.
You can learn more at portablecontacts.net.
And it exposes--it's basically vCard data but exposed
in a more modern way as are JSON or XML.
So then it's very easy to go and get access to that data
and it's in the standard format.
And what's cool is in addition
to just traditional webmail address book providers,
we got together with the OpenSocial community
and we standardized so that OpenSocial,
which has a much richer set of requirements around
building social applications into websites
and so forth, but they have a bunch
of externally facing APIs, one of which
is get my profile data or get my friends' data,
which is very much the same.
And so we were able to work together
and wire align portable contacts
and the OpenSocial piece about getting people.
So any OpenSocial provider out of the box
is also a portable contacts provider.
So if you wanted to do import
from MySpace or Hi5 or Friendster or Orkut
or any of these sites that support OpenSocial,
you can do it the same way as you can
from your Gmail contacts.
So that's very cool to see that convergence happening.
And it's all because we got together and said, hey,
we believe that we can grow the pie substantially
for everyone if we can stop bickering over
the little details of how you describe a phone number
and focus on building value higher up in the stack,
and that's what allowed this to move.
And a cool thing, this guy Sean Sullivan
who just found out about portable contacts
out in the community and-- whipped up an Android app.
And now you guys all have your own Android phones,
maybe you can do this too.
It's called jpoco.
And again-- so you could import from
any portable contacts provider into your Android phone.
So here he's doing it with Plaxo.
And all of a sudden, boom,
you've got all my information there, right?
So it's neat how people come up--
We didn't even really anticipate this use case
when we thought about portable contacts,
but because it's a standard,
it's so easy for people to go off and build the stuff
and anybody can go use it.
And so the last thing I wanted to say
is so now you're into the site.
Now you've got your friends list.
But what you really want to complete that virtuous cycle
is when you're making activity
or sharing things on that site,
you want it to flow back out into your aggregator of choice,
whether that's Plaxo or FriendFeed
or Facebook or Twitter
or Windows Live or Yahoo Updates.
I mean, pretty much all the major players have these now.
And so you'd like the user to be able to say
just like, well, wherever you keep your contacts
bring them in.
Wherever you aggregate your activity,
send it back out because that's how
other people are gonna find out what's going on
and come find out about your site.
And so I think one of the coolest implementations
here is something that Google made called FriendConnect.
And FriendConnect does a lot of cool things
but what it does is it lets any website
add social functionality
buy just copying and pasting a few lines of JavaScript.
So sort of like how in AdWords
you can just easily put ads on your site,
with FriendConnect you can easily put
social information on your site.
And Google hosts all the data
so that you don't have to do any back end programming.
You just have to--
Let me make sure I'm still signed in properly
and everything.
So this is a little site called My Latest Piece.
This is like a local artist
that wants to show off his stuff.
And a typical example of where traditionally
you'd have just kind of a standard website
that doesn't really have its own programmers
or ability to build a bunch of social information
and all that kind of stuff.
But with FriendConnect they just drop in
this widget, and so I've signed in here.
And let's see.
Maybe I'll show you the interface.
Let me sign out.
And you can see these are little iFrames,
and so it's just easy for me to say, "Join this site."
And then under the hood, Google's powering this pop-up
so they get this OpenID sign-in experience.
So I'll use my Google account, so again,
I don't have to create a separate account on--
Let me do a different user.
On "My Latest Piece,"
I can use my Google account.
And then I can also go--
Now I'm in the site and I can see which
of my friends are on this site.
So that same cool experience I showed you
but with even less work than it would've taken
to build it yourself.
And if I go and look at my settings,
what's really cool is not only can I get into the site,
I can then hook up the other tools and services that I use.
So I can pull in Twitter, I can pull in LinkedIn,
I can pull in Plaxo and have that information on the site.
And again, Google's done all the hard work
behind the scenes and so the site can just
sort of take advantage of having richer profile data
and more connections.
But crucially down here what you can see
is this option: Publish my activities
to the sites I've joined and add to my networks.
So what that means is if I share activity on this site,
it'll go back into my Plaxo stream.
So for example, if I say--
Going down here and say...
"Great piece! Hi from Google I/O."
And now you'll know I couldn't have faked it
because I wouldn't have known
that I was gonna be giving a talk here
is the theory, right?
All right.
You win some, you lose some.
[laughs]
O. There we go.
Okay, and then I'll post that rating.
And so then my rating will show up down here.
Then my rating will show up down here.
Hmm, let me refresh that.
If we were using Wave
you would've seen it, like, character by character.
Oh, yeah, so, "Hi, great piece from Google I/O."
So that's cool.
So people on that site can see that it's me
and they can see my real photo.
But then what's really cool
is I can go back to Plaxo and let me sign back in
as my account that I was using.
And there it is.
Joseph posted on a FriendConnect site.
Joseph wrote a review.
"Hi, from Google I/O."
And it's on My Latest Piece.
And so I've written my friends and they'll see this.
They may never have heard of My Latest Piece, right?
But they can not only see that I did this thing.
They can just click through and see it over there.
And then they can come in and join their account.
And so that's that virtuous cycle that I was talking about.
And the thing to me that's so cool about this
is not only does it allow me
to use lots of different websites and share activity,
but Plaxo's never heard of My Latest Piece, right?
It's not like we wrote a special plug-in
to interface with mylatestpiece.com.
We'd never heard of them.
But because it's using open standards it just works.
And it's using the OpenSocial RESTful APIs with OAuth,
all this same stuff you keep hearing about.
And that's what makes it work.
And what's even cooler then
is that because it's all open standards,
Google can go make a service like FriendConnect
where anybody could implement this themselves,
or you can outsource it to somebody like Google
and it all just sort of works.
That's only possible in a world
where you have these open standards.
And this is really fertile ground.
Most people are still not taking advantage
of this stuff and it is just gonna be killer
for all of your sites.
You're gonna wonder, I think, within a year
how people possibly thought that it was reasonable
to put out a new startup.
And it's like, all right, now we just have
to get 10 million people to sign up
and upload photos and connect to 100 friends
and share a bunch of activity
and come back to the site daily and we'll be set.
Like, that's such a high bar when you think about it.
It's just so hard to do that on a bunch of different sites.
And now you don't have to.
And so I think that the real benefit
will be all the smaller developers
who can just build these sites
that can kind of grow and thrive
much the way you can link to lots of different websites.
And a small website can be linked to
just as easily as a big one.
Andthen it can start to rise in relevance,
except now the data's moving with it as well.
And so I mentioned Facebook a few times.
A year ago I think there was a big question mark.
In fact, when I gave that talk where I mentioned--
I didn't show you the full slide.
There was the Open Stack piece and then we sort of said
well, Facebook, they're really not doing
any of this Open Stack stuff.
Although to be fair, their own stuff,
Facebook Connect and the Facebook platform,
it's conceptually very similar.
It's still me taking my account to another site,
bringing my friends, sharing activity back.
And so it certainly is sort of a similar worldview
that you'd want to consider.
It was just sort of annoying to have to say,
well, gee, I got to build it twice,
once for the Open Stack and once for Facebook.
But then a funny thing happened over the past year.
Facebook decided gee, it's time to open up our stream
which many thought was the most closely guarded
piece of data on Facebook.
But they said, no, we're gonna open it up to developers,
and what's more, we're gonna do it in an open standard way
with activity streams.
And then they joined the OpenID foundation
And then they decided, well, gee, we're not just gonna
join the OpenID foundation.
We're gonna roll out OpenID ourselves.
And then not a month later, the big one--boom.
Facebook actually supports OpenID as a relying party
and does the OpenID and OAuth and portable contacts
all rolled into one.
And so they are very much in the game now,
and that's really exciting because obviously
Facebook is a huge site and very innovative
and they've got a lot of users and a lot of data.
And so you as a site obviously are gonna want people
who are on Facebook to come and use it.
Now it's certainly the case that Facebook's
not everything on the web, right?
In fact if you look at stats of these sites
that allow you to log in from lots of different places,
what's very interesting is, "A", the pie chart has
a lot of big wedges, so you know,
there's a lot of Facebook users share
but there's also a lot of MySpace users,
a lot of Google users, a lot of Yahoo users,
what have you.
And the other thing that's interesting
is that the relative sizes of the wedges
change a lot based on the type of site that you're going to.
So I believe on snoopdogg.com, which accepts OpenID log-ins--
think about that for a second-- using JanRain's RPX...
then the MySpace is more predominant.
But on user voice, Google's more predominant.
And on other sites, Yahoo's more predominant.
And especially internationally it's very different.
And so when you think about that,
you as a developer,
especially you as an individual site owner,
you really have no loyalty per se
to one side or the other.
You just want your users to be able to come in
and use whatever data they already have.
You don't want to be in the business of having to say,
"You can play here but you can't."
And so what you really want
is to be able to just write it once
and have it work across all these websites.
And so it's very exciting to see
more and more companies converge around this.
And there's a whole ecosystem building around this.
So what I showed you--all those feeds coming in, right?
Well, Plaxo, we were one of the first to do this.
We had to build it all ourselves,
so we had custom agents and pullers and crawlers.
But now there are these great startups out there
like Gnip, if you haven't heard of them.
They go out and they figure out how to get feeds
from all these different websites.
And then they just push it to you in real time
and they do all the scalability stuff.
So we use them for a bunch of our feeds
where we say, like, anytime somebody publishes on Delicious,
we know however many Delicious users
are also connected into Plaxo.
And they just ping us with oh, hey,
J. Smarr just saved another bookmark.
And so it shows up, like, within a minute in our site
and doesn't require us to have load.
So another benefit of these standards
is that it allows for, kind of like Google FriendConnect,
it allows for people to come in and add value
into the ecosystem even though they aren't themselves,
you know, end destination.
So very exciting to see how this is all very frothy.
So just to wrap up and then
we'll have some time for questions.
As I said at the beginning,
I hope I've shown you that the web is going social
and the social web is going open.
And in fact, I think I can now say it
even more strongly than that.
I think that the web is actually now social
and the social web is now open.
And that means that it is now time
for you guys to actually get involved
since the only thing waiting now
is a bunch more developers who get it
who want to push the envelope and make great sites
that are easy to use.
So in conclusion, it's time to start opening your sites up
to users that already have accounts.
You're not the first website that they're ever used
and you should start to take advantage of that.
Give them a socially-tailored experience.
Don't make them start over from scratch
with their friends list.
And then think about how you can let your users
syndicate activity back out into their stream
and let you ride that virtuous cycle
'cause it's gonna be a great ride.
Thanks a lot.
[applause]
And one last comment.
If you want to stay up more to date
with what's going on,
I know this is a very fast-moving field.
One thing we've tried to do to help is a few of us,
Dave Recordon and Chris Messina and John McCrae and I,
we do a sort of weekly video podcast
called TheSocialWeb.tv.
Just sort of quick kind of 10 to 20 minute chunks
of the latest news and trying to understand
what's going on and help make sense of it in a way
that's not too technical but helps bring things out.
And we often have guests from the people
that are building things, so in addition
to following me on Twitter or looking at my blog,
this I think you'll find a probably useful resource.
So I encourage you to check that out. Yeah.
man: Thank you for the good presentation.
I appreciate the excellent input.
Quick question.
In terms of management,
is there a tool that provides an integrated view
over all those sites so that I don't have
to go into each container and manage it separately?
Smarr: So the question is, "Yeah, how do you manage?"
Well, certainly in part that's what services
like Plaxo are trying to do.
They're trying to give you a single place to go
to see what the friends you care about
are sharing all across the web.
So if I have Flickr friends, I can see their photos.
If I have Picasa people, I can see their photos.
I think there's a lot more work to be done
above and beyond that in terms of managing
permissions and sharing and notifications
and a whole bunch of other stuff.
And I think that's gonna be another fruitful area
of innovation.
So--and I think as more people--
When I think of questions like this
I always think of the famous William Gibson quote.
"The future is already here.
It's just not evenly distributed yet."
So there are people like me
who already have that pain in spades.
There's still a lot of other people
who really aren't using that many of these tools yet.
But I think as more and more people
find it easier to get into more and more of these sites,
tools that help you manage all that
are going to become more and more important.
I think it's going to be a great opportunity for innovation.
Yeah.
man: I saw on Plaxo that you guys still have
the either Facebook, Gmail, Google,
and even having your own sign-up registration system.
Would you advise websites to actually just do
Facebook and Google and not have their own
registration system anymore?
Smarr: Yeah, so good question.
Is it time to get rid of my own registration system?
Well, so a lot of sites that already have native users,
like, we have a bunch of users that already signed up
for Plaxo before this stuff came out.
We have to have some way for them to log in
with their existing credentials.
For new sites, I think there are sites--
like, so there are sites that have already gone that route.
There's a cool site for discussing technical material
called Stack Overflow and they're 100% OpenID.
And there was a cool social bookmarking site
called Magnolia that went 100% OpenID.
And I think Plaxo, we'd like to get
to be a 100% relying party as well.
So that basically there'd be no new Plaxo registrations.
There'd already be existing sites.
I think, depending on exactly what your audience is,
you have to ask yourself, you know--
It's pretty true that probably pretty much everyone
has an OpenID right now because
all the bigger portal providers have it,
but if you think, well, gee,
maybe my users are particularly non-technical
and not likely to have those,
you might decide to build your own one.
But I think it's definitely getting close
to the point where a lot of people could
just get rid of it altogether and just say, hey,
go sign up for a Google account if you don't have one.
And the other advantage there is there's a lot
of stuff you have to do around managing account creation.
People try to create spammy fake accounts and all of that.
And Google and Yahoo and all those sites
have way more detailed paranoid teams
figuring out how to track and trace that stuff.
And so the advantage of outsourcing authentication
to someone who's gonna do a better job than you and
they're gonna keep the passwords more secure and all that.
It's not just not having to write the code,
but it's you actually get a more secure experience
at the end so I think that's another benefit.
Yeah.
man: Well, looking the other way,
you have many people who have IDs on multiple sites
that were not OpenID originally.
Is there some way they can coordinate those
so that their accounts can be linked retroactively?
Smarr: Yes, there is.
I'm glad you asked that.
So it's a good point, right?
I have lots of URLs of my profiles around the web.
They're not all OpenIDs, and even if they were,
it would be kind of annoying to have
to connect each one individually.
And so there's a way you can do this much more easily.
One of the things that people figured out a while ago
was that you could embed semantic information
into the structure of links on the web themselves,
a thing called microformats.
So you could put in, if I have my website
with contact info or things like that,
we do this sort of simple agreed upon set of CSS classes
that a computer parser could come in and grab data.
And one of those was if I'm hyperlinking
from one of my profile pages to another profile page,
I can put rel="me" in the tag
and that says this is another profile page about me.
And then you can follow those rel="me" links.
And the idea is so if I can--
say I use my Google profile as an OpenID.
And then it has rel="me" links to my other profiles.
I probably couldn't have spoofed that
without being able to control that Google account.
And because I control that Google account,
I can prove that with OpenID,
you can kind of trust by transitivity
that those other sites are mine as well.
And then you can follow those links downstream and so forth
and you can actually kind of build
a whole set of identifiers about me.
And we use this in Plaxo.
I didn't put this in this demo but maybe I should've.
Google, again, has come and made this even easier.
The have this thing called the Social Graph API
where they basically said, gee, crawling the web
is kind of hard, but we've already done that
and we've got it sitting over here on a hard drive
as I understand it.
So why don't we just serve up all those me links
in a simple API?
So if you look for the Google Social Graph API,
you can literally put in any URL and say
give me all the downstream rel="me" links.
And they'll give you all back in one shot.
And so we do this when every time somebody
either signs up with an OpenID,
or say they hook up their Twitter feed.
You know, Twitter-- a lot of these sites
put these rel="me" links in there for you
so you don't have to be a hacker to do it yourself.
LinkedIn, a bunch of these sites do that.
We then follow all those links,
and those are all ways we know the user.
And if they're mapped to services we know,
like, we know what a Flickr URL looks like.
We know what a Twitter URL looks like.
We can use it to say, hey,
looks like you're a Flickr user too.
Why don't you hook up that feed?
And so you get even more downstream benefit
and richer profiles, so-- and that's a really nice way
of sort of using the link structure of the web
to get even richer data beyond just
the initial OpenID handshake.
Yeah.
man: Hi, thanks for your talk. Smarr: Sure.
man: I just had a question on what you feel browsers
could do to help enable all of this.
As I see OpenID integration has been a little difficult
because of the whole UI being a pain to deal with.
Smarr: Right.
man: So what can browsers do to fix this?
Are you aware of any browser projects,
Firefox, Opera, whoever--
Smarr: Yeah, yeah, yeah.
So browsers can be a huge help in this.
It's a bit of a chicken and egg thing
because on the one hand, if you think about it, the browser
is in this wonderful, privileged position
where it actually knows all the different websites
that you go to, right?
It's a real pain to say
tell me which of these 50 websites you use
so that I can provide you with a tailored experience,
whereas the browser actually knows that.
And the browser also presumably
has privileged information to your credentials
on these websites because it's watched you link--
sign in to all those.
And the browser could present-- you know, secure Chrome
that can't be phished and you can't redirect
to a fake site and all that kind of stuff, right?
And there have been people that have done this.
VeriSign Labs made this plug-in called OpenID Seatbelt.
And there's a thing called IDIB,
Internet Identity In the Browser,
that was a project that did that.
I think Mozilla also-- they showed a video
of some sort of OpenID in the browser type stuff.
There's a lot of potential there.
The downside, of course, is that getting
a browser with this upgraded functionality
on everybody's desktop is a real deployment challenge.
And so I don't think we can wait for browsers to save us.
I think there's gonna have to be a web native solution.
But I think making it easier for browsers
to come in and add additional value on top of that
and simplify the UI and be more personalized
is an absolute win.
And I would love to see things like maybe Google Chrome
could do that, right?
That's something that's going to be distributed
to lots of people that could add that kind of functionality.
So definitely great opportunities there
and has been some early work.
But it's mainly that deployment challenge is tricky.
Yeah.
man: You mentioned earlier for Facebook friends
you had a background process
that kept the graph up to sync and everything.
I was wondering if you do that for any other graph,
like MySpace or whatever, and if you've run
into scalability problems with that.
Smarr: Yeah, so scalability of refriending.
So our core business traditionally
is actually real sync.
So we have an Outlook plug-in and a Mac plug-in
and a Thunderbird plug-in and on and on.
And that does real, continuous background
full contact and calendar synchronization.
So we sort of already have
pretty good infrastructure for that.
And the reason we and almost all sites
just do a one-time import-- which as I mentioned
is sort of silly 'cause you miss all the downstream stuff--
is because when you're taking passwords,
it's not only kind of a liability
to take the password,
it's a real liability to store the password, right?
Because if that goes wrong or if you get hacked,
you're compromising all the other sites.
And so most sites just throw away the password
and only do a one-time import.
But once you get a long-live token,
whether it's a Facebook token or an OAuth token,
you know have the luxury of doing
that kind of repeated background import
and pulling in the information.
So you could actually get a lot more value
than when you just did the one-time thing
because you don't have the security problem.
So we haven't done as much as we should, to be honest.
Like, we don't do it right now
with when you do that Google hybrid flow,
we just pull them in once.
We don't look in the background, but we clearly should.
Like, we're being stupid not to do that.
And any site should.
And it's not really a scalability problem
because you can choose how often you want to do that.
You could do it once a week or once a day or whatever.
And in fact we haven't done this so much with these sites,
but in places like in OpenSocial where you have potentially
a large number of user accounts
that need to be updated with a service,
there's ways of sort of batching that.
So there's the so-called two-legged OAuth
where a service will talk to another service
and say, hey, you can trust me that I'm Plaxo
because I can prove that I'm Plaxo.
And so for these ten users in batch,
could you give me updated information?
And then they'll just hand them all over at once
rather than doing it one user at a time.
So there are tricks like that for scalability
above and beyond.
But it's really not that bad because it's just
a periodic thing in the background.
And maybe someday services like Gnip will help me
get pushes about my friend notifications as well as feeds.
I mean, really it's kind of the same problem.
Yeah.
man: A question in regards to OpenID and OAuth usage
within enterprises as opposed to outside of enterprises.
And the second part of the question,
integration of those with like Sun's old app
or Microsoft ID.
Smarr: Right. Great question.
So what about inside the enterprise?
Actually, it's funny.
They had a whole panel on this at South by Southwest this year.
And enterprises obviously face a lot of these same challenges
and there's a lot of opportunities there.
And traditionally they have been all of these
kind of one-off hacky systems.
So I think there's a lot of optimism now
that a lot of these technologies can be applied
inside the enterprise as well.
And if you don't know about this,
there's this thing called the Internet Identity Workshop
which is a kind of unconference where a bunch of people
in this field get together and work on these problems
and it's a fantastic thing.
We just had one earlier this month
and there was a whole big session.
You had guys from Microsoft
who know all the WS federation and trust stuff,
and you had people from Google and you had other people
and they're all getting together and kind of figuring out
what is different about the enterprise use cases
and how does that work with this stuff.
A lot of very interesting progress being made.
There's already some early examples.
There's a cool example where sun.com,
they gave all their employees sun.com OpenIDs
and the only way you could get one
is to be a Sun employee.
So you could imagine if Amazon wants
to give them an employee discount,
you just log in with your Sun account
and all of a sudden it verifies it, right?
So there's all kinds of interesting models like that.
I think it's still a little bit early there.
And there's a few extra levels of paranoia
that maybe need to be layered on top
as extensions or something depending
on how big the enterprise is
and how much they want to revoke and change things or whatever.
But it also makes a ton of sense to build--
I hope somebody would go build OpenID plug-in
for something like Active Directory
'cause that's the point is-- companies have
the credentials already of their employees.
You'd like to be able to expose that in a way
that doesn't require all these consumer--
like Yamir, poor Yamir wants to build this great
kind of like Twitter-like application for enterprises.
But they have to go do these one-off,
like, let me poke a hole in the firewall
and connect your LDAP and you dump out and send me--
It's horrible and it's not core to them.
So if you could just say, well, you could log in
with your OpenID, then it might make it a lot easier.
man: It just so happens at PGP we built a system
using--an OpenID system using a PGP key.
Smarr: Oh, yeah, exactly, yeah.
man: Because we have this large database
on the global directory.
And people got keys in their machines and there's code.
Smarr: Yeah. man: It works very well.
Smarr: That's fantastic, yeah. So I really hope that--
man: So my question is--
Smarr: You've earned a question.
man: I understand that Google wants to provide
the authentication, but what if I want
to use that to log in to Google?
You think they're willing to open up
to using another OpenID provider?
You think it's gonna level off?
Smarr: Will the big guys be relying parties too?
Well, as Google would say,
they actually already are a relying party
to thousands of other websites because
of their Google apps for your domain project.
So if you're a company that wants to host
Google apps for your domain,
you can use your own log-in system
and get a hosted version of Gmail.
Now it's generally not OpenID on the back end.
It's things like SAML.
But it's conceptually the same thing.
And obviously I can't speak for any of the big companies,
but I think that they all have the same problem.
So I mean, the first-- the best example so far
is Facebook becoming an OpenID relying party.
And if you watch the interview that we did
on The Social Web TV with Luke Shepherd
who was the main engineer at Facebook who built that,
what he says is just because we're big
doesn't mean we don't care about growth.
In fact, quite the opposite.
And so they have all the same pain with sign-up friction,
and getting contacts, and getting information,
and having lost passwords.
And so they're actually very motivated to make that work.
I think the things that are most holding it up
are actually more downstream.
So for example, if you want to go download a desktop client
or use it on your BlackBerry or your mobile phone,
what do you do then?
And there's good answers that are being worked out.
But it's not quite to the point now
where they feel like for their user base
and their existing deployed apps and all that,
they can just switch over.
But I do believe it's coming because
it really will just drive business value
and you'd be stupid not to do it.
It's just a matter of who's going to move first.
man: So what do you think it's going to take
to leverage, like, the banks, the credit cards,
the bill paying sites to start doing this?
Smarr: How do you go to higher value transactions?
Well, that is something that
a lot of these people think about.
And again, this--a lot of this is making the site
more user-friendly,
and at the same time, it's actually making it
more secure because you're not giving away your password
and there's a lot more kind of cryptography under the hood
baked into these OpenID and OAuth.
And so to me, it's sort of this rare scenario where
we're actually making the stuff more user-friendly
and more secure at the same time.
And I think the higher value transaction,
people like banks and stuff,
they'll probably take a bit of a wait-and-see attitude
and see how this plays out in the lower value space
and then kind of scale it up.
But there's already work being done with extensions
about being able to prove that you used
a higher level, kind of two factor authentication
or things like that that--so I think we'll see it.
I mean, again, nobody wants this friction, right?
If I go check out on an ecommerce site,
I don't want to have to put in my credit card
over and over and over again if I can pull it in securely.
So I think I'll see that.
And with three seconds left, thank you very much
and go be open and connected.
[applause]