proposal for unified interface

[gattis]

I think the way this is going to be most useful to people is to
aggregate the likes in one place, allow the user to select which
services they want to allow access to their like, and let services
query the open like database for the data they have available to them.

On the user side:

- Propose one "like" button (or possibly a like+dislike or a rating
from 0-5)
- As the user clicks it, tiny popup allows them to "identify"
themselves using one of many services (facebook, twitter, google, or
openID)
- One more tiny popup asks you to select the like as a "public" like,
meaning all services have access to it, or a "private" like where the
user checks which services have access to it

On the service side:

- An API query to get all the likes from the openlike database that
have been authorized for your service


--
Subscription settings: http://groups.google.com/group/openlike/subscribe?hl=en

[Kevin Marshall]

+1 to all this (which is a very nicely summed up version of what I
posted last night).

- Kevin
http://catchafire.org

[Jonah Peretti]

That would be awesome but too complicated in terms of user adoption.
Here is another strategy:

"PublicLike"
1) All likes are public AND in the public domain
2) Users only like something if they want the world to know they like it

Then you have an advantage over FB because you don't have all the
legacy privacy issues of FB or all the overhead of managing who sees
your likes. It is more like Twitter where everyone who uses it knows
it is public. The likes can even go to the Library of Congress just
like tweets.

Publishers and web apps would want to use PublicLike it because they
would get the benefits of sending likes to FB and many other services
with one simple click. Just add the PublicLike to your site to
integrate with FB, Google, Hunch, etc. and users know that it just
takes one simple click to share what they like with all the services
they use.

Best of all this would generate a massive public database of user
likes so services could compare their users to users in the universal
public like database and make recommendations based on users that are
not even in their database. Or a smart hacker in his basement would
be able to create a recommendation engine without having to figure out
how to collect all the taste data.

[Sachin Bhatevara]

+1 to Jonah's proposal and agree that Gattis's proposal while nice maybe too complicated for users. I particularly like the fact that these likes are in the public domain and anybody who wants can have access to these and build recommendation systems on top.

[gattis]

Agreed it would be much simpler to make everything public. It's hard
to gauge how people feel about this.

I think at the least you would have a dashboard on OpenLike where you
can choose to only make your data visible to certain services, kind of
like twitter's "private profile" option which is rarely used but takes
care of the people who actually care about privacy.

I think a lot of the outrage against facebook with respect to privacy
is just how cavalier they are about opting users in to new services
that use their personal information. I personally feel like the only
time I log onto facebook these days is to revert my privacy settings
every time they make a "design" change. I think we all would agree
this is abusive to users and to not go down that road with OpenLike.

[Alex Iskold]

I really like the idea of single like button, which goes into an
independent storage.
I think that for all this to work and compete with Facebook, we'd need
to:

* Provide OpenLikeDB which stores likes ( should be flexible for other
actions as well )
* Provide single LIKE button for publishers, which also supports
posting to other places like FB, Twitter, etc,
if the user chooses so.
* Support Facebook page markup - that's the bit they have that's nice

So with this, user's choose where the data goes, but it always goes to
the OpenLikeDB,
which is under an ORG umbrella.

[Jonah Peretti]

This is prefect because then I don't have to beg for taste data from
GetGlue and Hunch. I can just use OpenLikeDB for my training data.
;)

[Alex Iskold]

Exactly ;)

And even now you don't need to beg:
http://getglue.com/api.php

On Apr 23, 3:58 pm, Jonah Peretti <jo...@buzzfeed.com> wrote:
> This is prefect because then I don't have to beg for taste data from
> GetGlue and Hunch.  I can just use OpenLikeDB for my training data.
> ;)
>

[TP]

So would clicking the "like" button take you to openlike.org where you
would separately OAuth into fb and any other services you want to
publish the "like" to?

Or would the publishing site that is embedding the OpenLike js pass in
auth tokens to the OpenLike js so that the js could call fb and other
services' APIs to publish the "like" and then record it to OpenLikeDb?

[stevecrossan]

+1 to PublicLike.

Is the idea that the public likes would (at your option) have your fb
id / other service id associated? i.e. we're generating a stream of
public like events of the form 'user with this id liked this url'?

[TP]

Steve, yes, that's what I was assuming.

We still need to figure out how the mechanics of finding out if the
user is logged in to which service, getting them logged in if they're
not, etc will all work.

[Steve Crossan]

+1

do you also want to support anonymous likes (-> have to get into spam detection)

would also be nice if a user can 1 time authenticate to openlike.org and associate fb id etc, there and then not have to do it on each like. Openlike Connect!

--
Steve Crossan
+1 650 276 0788

[Andrex]

How about integrating it with XAuth (http://xauth.org/) so that it
automatically knows which services you use?

[rdza]

+1 for xauth integration to solve this new (same as the old) nascar
problem

[Jonathan]

I'm strongly in favor of PublicLike -- and I hereby rescind my idea of
PrivateLike as contrary to the spirit -- but I'm still trying to
picture the actual flow. Can someone lay out a straw man of how
PublicLike would work for the first-time user?

I'm also strongly in favor of keep collection of data about the
'liked' page or object down to the barest minimum for now.

I'm concerned about 1-5 stars or thumbs up/down as meaningless. I'd
instead prefer a small optional text box where the user can explain
their 'like.' Given the wide range of possible meanings of a 'like'
gesture -- this is pretty vs. this is interesting vs. this is funny
vs. this is morally correct vs. this is smart -- we should leave
meaning to the 'liker.'

On Apr 23, 12:24 pm, Jonah Peretti <jo...@buzzfeed.com> wrote:

> That would be awesome but too complicated in terms of user adoption.
> Here is another strategy:
>
> "PublicLike"
> 1) All likes are public AND in the public domain
> 2) Users only like something if they want the world to know they like it
>
> Then you have an advantage over FB because you don't have all the
> legacy privacy issues of FB or all the overhead of managing who sees
> your likes.  It is more like Twitter where everyone who uses it knows
> it is public.  The likes can even go to the Library of Congress just
> like tweets.
>
> Publishers and web apps would want to use PublicLike it because they
> would get the benefits of sending likes to FB and many other services
> with one simple click.  Just add the PublicLike to your site to
> integrate with FB, Google, Hunch, etc. and users know that it just
> takes one simple click to share what they like with all the services
> they use.
>
> Best of all this would generate a massive public database of user
> likes so services could compare their users to users in the universal
> public like database and make recommendations based on users that are
> not even in their database.  Or a smart hacker in his basement would
> be able to create a recommendation engine without having to figure out
> how to collect all the taste data.
>

[Tom Pinckney]

Does Facebook support XAuth?

I figure at a minimum to have publishers be interested in OpenLike we need to support pushing "likes" to FB.

[Will Meyer]

> Does Facebook support XAuth?
>

No. Its demos only, and none from FB.

> I figure at a minimum to have publishers be interested in OpenLike we need to support pushing "likes" to FB.
>
> On Apr 24, 2010, at 6:54 AM, rdza wrote:
>
> > +1 for xauth integration to solve this new (same as the old) nascar
> > problem

XAuth, functionally, doesn't really solve nascar (IMHO). It allows
you to query for services (by hostname) known a priori. Its fine if
you want to tell if someone is logged into Twitter or logged into
Facebook (assuming those services eventually support it), but it
doesn't actually extend to new services not known by the client
beforehand, nor does it handle the "I use this service even though I'm
not logged in right at this moment" cases. At least not in its
current incarnation/implementation.

[Tom Pinckney]

On Apr 24, 2010, at 9:03 AM, Jonathan wrote:

> I'm strongly in favor of PublicLike -- and I hereby rescind my idea of
> PrivateLike as contrary to the spirit -- but I'm still trying to
> picture the actual flow. Can someone lay out a straw man of how
> PublicLike would work for the first-time user?
>

Good question on how the actual flow should work. I think we need input from publishers about what they'd want.

Initially, I think we need to go ahead and continue pushing likes to sites like FB, Digg etc and not rely on them polling the OpenLikeDb. Otherwise adding the OpenLike button will result in less traffic back to the publisher. But to push a like over to one of these other services, we need to have the user OAuth into the service. There are a couple of ways this could be done:

1) The publishing site could have the user OAuth in to whatever service the like will be pushed to and then give the open like .js the access token(s), user id etc of the currently authenticated user so that the openlike .js could use the fb api to publish the like and record the user's identity and like into the OpenLikeDb.

2) Instead of the publisher's site doing the OAuth, the openlike code itself could prompt the user for which services they want to publish the like to, OAuth the user between openlike and the service, publish the like to the service and record the user's identity on that service along with the like info in the OpenLikeDb.

Option number one gives the site more control since it's the publisher's site that the user is fb connecting in to so the publisher can use FB APIs. Option number two is simpler for publishers that don't care about having the user fb connect in to their site and just want a drop-in way to send likes out and get traffic back.

What do you all think? Are there other ways we could do this?

[Steve Crossan]

Another plus of option two is user would be able to like several sites
in the same session without another login

[Steven Willmott]

Lots of great thoughts, here. In trying to get my head around it I
tried to come up with a list of the objectives split up by party.
Might this be something like this:

For users:

- Allow users to express the fact that they like something (and maybe
why they like it)
- Enable them to share that with others
- Potentially allow their likes to be used to improve their web
experience in participating sites (see more of the things you like,
less of what you don't).

For publishers:

- Find out what people like
- Find out what a particular user likes (to advertise the right
things to them or just improve their experience)
- Get exposure elsewhere for the content that is being liked (i.e. in
the places where the likes are being shared).

For the Web as a whole:

- Know what people like (on aggregate, per individual, which likes
are trending now etc.)
- Know useful stuff about the things people are likeing (+1 for
including good meta data where possible - that proposed by FB or
something else)
- Enable the correlation of likes with other types of data to do
clever things.

I don't know if this is a good summary, and probably misses some stuff
but maybe it's helpful. There are also a lot of different ways of
implementing it but it seems to me that key would be:

- It needs to go beyond "unauthenticated likes" (i.e. a like needs to
be bound to an identity, be it an "openlike ID", a facebook account, a
twitter user or whatever).

- The way the like data can get re-used is key to success - to
whether publishers will pick it up + whether users which actually use
it.

A simple implementation would be a kind of "twitter for likes" where
the javascript button simply publishes to a stream of likes classified
by individual user and but the publisher / object liked. The stream
would be public and could tracked by publishers and other services the
user is using (publish my likes in my activity stream, just like you
publish my tweets).

More advanced would be having likes optionally private and allowing
access to third parties using oAuth (+1 for that). So when the user
arrives on a site they can authorize the site to use the like data to
make the service better. Further, APIs could provide access to
aggregate like data (long term and short term trends)

The big question here is also how to provide the backend
infrastructure to capture and republish likes. Its seems like bad
architecture if this ends up being a single entity, but perhaps if the
formats are all agreed, any current identity provider could become a
"like provider"? Architecturally it seems to me that the likes belong
to the user, so they should probably reside with their chosen identity
provider (who should provide 3rd party access, allow the user to
migrate them in the
future etc. etc.)

[rdza]

> XAuth, functionally, doesn't really solve nascar (IMHO). It allows
> you to query for services (by hostname) known a priori. Its fine if
> you want to tell if someone is logged into Twitter or logged into
> Facebook (assuming those services eventually support it), but it
> doesn't actually extend to new services not known by the client
> beforehand, nor does it handle the "I use this service even though I'm
> not logged in right at this moment" cases. At least not in its
> current incarnation/implementation

"To view and modify any currently enabled browser XAuth tokens, go to
xauth.org/"

By providing a service for a script in a browser to look up what
tokens may have already been pushed from another tab, session, or
device, xauth definitely seems to handle the "extend to new services
not known by the client beforehand" case, the client being a newly
spawned page trying to find out what services are preauthenticated. Is
this discovery not the essence of the nascar problem?

I agree that it doesn't handle the "I use this service even though I'm
not logged in right at this moment" case. Maybe webfinger discovery
could be adapted for this purpose, but it requires an email address to
query, and then you have to discover the email.

[incorvia]

This whole thing is very similar to something I pitched to Ben Parr
over at Mashable. He told me he would talk to his partners on it, he
then wrote me saying he couldn't work on it because maybe they were
already doing it. I had my own ideas about how this would work in
terms of work flow. Each person would have a profile with a website,
of which services they would like to be active on their 'account'.
Then when they visit a page and click 'share' (a button that presents
the aggregated shares of all the services they are on) they will be
presented with a share box with those services as default. In
addition there would be checkmarks to enable or disable different
services similar to the way hootsuite, or tweetdeck handles it.

Part of the problem of the workflow is handling how different services
deal with things. When you 'like' something on digg, or facebook, its
a bit different than sharing something on facebook, or twitter, etc..
nice to be able to accomodate both.. plus new styles that are similar
as they come into existence. I've drawn some mockups of how you might
handle this. if anyone wanted to see them.

[Will Meyer]

On Sat, Apr 24, 2010 at 18:43, rdza <rdc...@gmail.com> wrote:
>> XAuth, functionally, doesn't really solve nascar (IMHO).  It allows
>> you to query for services (by hostname) known a priori.  Its fine if
>> you want to tell if someone is logged into Twitter or logged into
>> Facebook (assuming those services eventually support it), but it
>> doesn't actually extend to new services not known by the client
>> beforehand, nor does it handle the "I use this service even though I'm
>> not logged in right at this moment" cases.  At least not in its
>> current incarnation/implementation
>
> "To view and modify any currently enabled browser XAuth tokens, go to
> xauth.org/"
>
> By providing a service for a script in a browser to look up what
> tokens may have already been pushed from another tab, session, or
> device, xauth definitely seems to handle the "extend to new services
> not known by the client beforehand" case, the client being a newly
> spawned page trying to find out what services are preauthenticated. Is
> this discovery not the essence of the nascar problem?

All I was referring to is that you an get the set of hosts back, but
you may not know what they are, have icons to show, etc -- really its
a "do you have this service yes/no" from the client, for all intents
and purposes, unless you're just trying to show a list of the hosts
for its own sake, but thats only really useful for the xauth site to
do.

>
> I agree that it doesn't handle the "I use this service even though I'm
> not logged in right at this moment" case. Maybe webfinger discovery
> could be adapted for this purpose, but it requires an email address to
> query, and then you have to discover the email.

Yeah I think that's the ticket. I had proposed doing this via
webfinger as part of OExchange, and if XAuth extends at some point
then maybe it could even be used as a cache for this kind of
webfinger-resident info.
(http://www.oexchange.org/spec/#discovery-personal)

[NickMikhailovsky]

Taking into account the discussion on the general system design (see
crowdsourcing ontology thread):

1. Services should give user a meaningful choice of relationships to
items
2. User can define a custom relationship

I suggest the following type of user interface for end-users (ugly -
lacks icons - but you get the idea):

http://picasaweb.google.ru/Nick.Mikhailovsky/OpenLike#5464568703340612050

On 25 апр, 16:59, Will Meyer <w...@willmeyer.com> wrote:

[Steve Crossan]

Part of the problem of the workflow is handling how different services
deal with things.  When you 'like' something on digg, or facebook, its
a bit different than sharing something on facebook, or twitter, etc..
nice to be able to accomodate both.. plus new styles that are similar
as they come into existence.  I've drawn some mockups of how you might
handle this. if anyone wanted to see them.

Yes, it would be great to see mocks.

FWIW I favor a single button interface. I like the model that the user configures the social services they want to ping on openlike.org (maybe the first time they do the like) with a standard set of defaults. That could be the point of doing the account connection also. 

 

On Apr 24, 12:38 pm, Tom Pinckney <thomaspinckn...@gmail.com> wrote:
> On Apr 24, 2010, at 9:03 AM, Jonathan wrote:
>
> > I'm strongly in favor of PublicLike -- and I hereby rescind my idea of
> > PrivateLike as contrary to the spirit -- but I'm still trying to
> > picture the actual flow. Can someone lay out a straw man of how
> > PublicLike would work for the first-time user?
>
> Good question on how the actual flow should work. I think we need input from publishers about what they'd want.
>
> Initially, I think we need to go ahead and continue pushing likes to sites like FB, Digg etc and not rely on them polling the OpenLikeDb. Otherwise adding the OpenLike button will result in less traffic back to the publisher. But to push a like over to one of these other services, we need to have the user OAuth into the service. There are a couple of ways this could be done:
>
> 1) The publishing site could have the user OAuth in to whatever service the like will be pushed to and then give the open like .js the access token(s), user id etc of the currently authenticated user so that the openlike .js could use the fb api to publish the like and record the user's identity and like into the OpenLikeDb.
>
> 2) Instead of the publisher's site doing the OAuth, the openlike code itself could prompt the user for which services they want to publish the like to, OAuth the user between openlike and the service, publish the like to the service and record the user's identity on that service along with the like info in the OpenLikeDb.
>
> Option number one gives the site more control since it's the publisher's site that the user is fb connecting in to so the publisher can use FB APIs. Option number two is simpler for publishers that don't care about having the user fb connect in to their site and just want a drop-in way to send likes out and get traffic back.
>
> What do you all think? Are there other ways we could do this?
>
> --
> Subscription settings:http://groups.google.com/group/openlike/subscribe?hl=en

[Louis Ameline]

I like Steven Willmott's statement ;) There is interest for many
protagonists in the Like matter.

I think there should be anonymous and public Likes :

- "Anonymous Like" would feed my personal list of likes (left is to
define where that "neutral" centralized database would be. Probably
providers like OpenId) and would be accessible for the websites that
use this information in a private/anonymous way (not Facebook at the
time) for content ranking for instance.

- "Public Like" would feed my personnal list of likes and everybody
that wants the info.

That's the idea. More config would be available on my "OpenLike
provider", to define exactly who can access what.

IMHO, OpenLike is rather meant to replace bookmarks than ratings but
if someone finds a nice way to do both at the same time...

Here's a humble mock-up to show that public/private modes don't have
to be too complicated : http://picasaweb.google.com/106920384122895693616/OpenLike#5465562123043650370

[Kingsley Idehen]

Louis Ameline wrote:
> I like Steven Willmott's statement ;) There is interest for many
> protagonists in the Like matter.
>
> I think there should be anonymous and public Likes :
>
> - "Anonymous Like" would feed my personal list of likes (left is to
> define where that "neutral" centralized database would be. Probably
> providers like OpenId) and would be accessible for the websites that
> use this information in a private/anonymous way (not Facebook at the
> time) for content ranking for instance.
>
> - "Public Like" would feed my personnal list of likes and everybody
> that wants the info.
>
> That's the idea. More config would be available on my "OpenLike
> provider", to define exactly who can access what.
>
> IMHO, OpenLike is rather meant to replace bookmarks than ratings but
> if someone finds a nice way to do both at the same time...
>

With regards to the comment: "IMHO, OpenLike is rather meant to replace
bookmarks than ratings butif someone finds a nice way to do both at the
same time... "

My thoughts:

A network record stored in a network data space (owned by you or shared
with others) is how you end up with:

1. Bookmarking++ -- Bookmarks with Context persisted to a Data Space
2. Tagging++ -- Tagging with Context persisted to a Data Space
3. Ratting++ -- Ratings with Context persisted to a Data Space.

No matter what you are trying to do, the end product is a collection of
structured data items where the following have to be discernible:

1. Entity
2. Entity Attributes
3. Entity Attribute Values (which may be References or Literal values).

Thus:

In Network Data Space (nee. Web Site for instance) resides the following
resides the following record in a document (a Data Container):

<#i> <#like> <#some-thingX> .
<#you> <#like> <#some-thingX> .
<#some-thing> <#name> "XYZ".
<#i> <#name> "Kingsley Idehen" .
<#you> <#name> "Louis Ameline".
<#i> <#type> <#Person> .
<#you> <#type> <#Person> .
...


The we can Find with precision (since the data is structured):

1. How many <#Person> entity types like <#some-thingX>
2. How many like an enity that has Name: "XYZ"
3. What do <#i> and <#you> have in common (i.e., how are we connected) .


All we need to do is make structured records in representations that
work best re. individual preferences.

To maximize network effect though, its important you do the following:

1. Name Things Unambiguously
2. Make Names Resolvable to their Structured Representations via Generic
HTTP URIs (e.g., My WebID or Name is:
<http://kingsley.idehen.name/dataspace/person/kidehen#this>)
3. Apply 1&2 to Entity Attributes also.

The Entity-Attribute-Value graph outlined above is what Names will
resolve too en route to building a boundless fractal mesh comprised of
EAV statements.

> Here's a humble mock-up to show that public/private modes don't have
> to be too complicated : http://picasaweb.google.com/106920384122895693616/OpenLike#5465562123043650370
>
>

--

Regards,

Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen