An alternative idea on how to open the like button - likecasting
12 views
Skip to first unread message
jopotts
May 3, 2010, 9:52:05 AM5/3/10
to OpenLike
I have an idea that goes a bit off the track of where this thread has
been going. Simply put, it's to keep the like button as it is but
broadcast the message.
It's fair enough for facebook to receive a 'like' message, but why not
also send that 'like' message to anyone else who wants to listen.
Facebook still hold the person info which is owned by them, but by
broadcasting the 'like' (who and what) to anyone who wants to listen,
then at least facebook don't also get to monopolise that information.
I envisage the details working like this: Publishers add a new bit of
openlike javascript just after the standard like button implementation
that intercepts the message as it goes off to facebook and sends the
facebook user ID and open graph page info to the openlike broadcasting
service. Anyone can register their site with the service (ie webhooks)
to receive the 'like' message. Simple (if feasible*).
By doing it like this, openlike doesn't have to keep adding buttons,
as it will be up to the sites to register themselves. Also, we don't
have to worry about storing any information as we're simply acting as
a pipe to keep the information open. There could also be another open
data capture service but that's another matter.
I'm not sure if users would want their likings broadcast - but they
could opt out if they want to keep the liking only sent to facebook.
The benefit and incentive to publishers is obvious - more link backs.
* If it's not possible to 'intercept' the message from the standard
like plugin, then it certainly is feasible to have a new button that
broadcasts in this fashion. It can take the user's facebook ID from a
hidden plugin.
@jopotts
been going. Simply put, it's to keep the like button as it is but
broadcast the message.
It's fair enough for facebook to receive a 'like' message, but why not
also send that 'like' message to anyone else who wants to listen.
Facebook still hold the person info which is owned by them, but by
broadcasting the 'like' (who and what) to anyone who wants to listen,
then at least facebook don't also get to monopolise that information.
I envisage the details working like this: Publishers add a new bit of
openlike javascript just after the standard like button implementation
that intercepts the message as it goes off to facebook and sends the
facebook user ID and open graph page info to the openlike broadcasting
service. Anyone can register their site with the service (ie webhooks)
to receive the 'like' message. Simple (if feasible*).
By doing it like this, openlike doesn't have to keep adding buttons,
as it will be up to the sites to register themselves. Also, we don't
have to worry about storing any information as we're simply acting as
a pipe to keep the information open. There could also be another open
data capture service but that's another matter.
I'm not sure if users would want their likings broadcast - but they
could opt out if they want to keep the liking only sent to facebook.
The benefit and incentive to publishers is obvious - more link backs.
* If it's not possible to 'intercept' the message from the standard
like plugin, then it certainly is feasible to have a new button that
broadcasts in this fashion. It can take the user's facebook ID from a
hidden plugin.
@jopotts
Kevin Marshall
May 3, 2010, 10:03:26 AM5/3/10
to open...@googlegroups.com
This is basically the idea I was trying to demo with
http://likefeature.com ... so I'm on board with it ;-)
- Kevin
http://friendstat.us
http://likefeature.com ... so I'm on board with it ;-)
- Kevin
http://friendstat.us
jopotts
May 3, 2010, 10:19:36 AM5/3/10
to OpenLike
ok - I've read some more and it looks like I wasn't off track, just a
bit out of step :)
I guess the different thing with what I'm thinking is to keep the
existing Facebook Like plugin as it is but then do some javascript
hackery to intercept the message. I'm not even sure if that's possible
though.
Is anyone out there building anything yet? (Other than you Kevin)
bit out of step :)
I guess the different thing with what I'm thinking is to keep the
existing Facebook Like plugin as it is but then do some javascript
hackery to intercept the message. I'm not even sure if that's possible
though.
Is anyone out there building anything yet? (Other than you Kevin)
Nathan
May 3, 2010, 10:21:15 AM5/3/10
to open...@googlegroups.com
It feels like multiple things are getting conflated here..
surely, a user asserting that they "like" something and storing that
information - is entirely different to - a user then sharing the fact
they like something / broadcasting a notification that they now like
something new.
The model feels wrong, what if it went something like this:
A user "likes" something, the assertion that user X likes Y is stored in
a personal data store for said user.
Each "like" is access controlled to be public, visible to group-x or
private.
Friends, Applications, Followers can then subscribe to the relevant
update streams of new "likes".
Optionally, The user can publish/push or "share" the like via x,y,z
networks.
Best,
Nathan
surely, a user asserting that they "like" something and storing that
information - is entirely different to - a user then sharing the fact
they like something / broadcasting a notification that they now like
something new.
The model feels wrong, what if it went something like this:
A user "likes" something, the assertion that user X likes Y is stored in
a personal data store for said user.
Each "like" is access controlled to be public, visible to group-x or
private.
Friends, Applications, Followers can then subscribe to the relevant
update streams of new "likes".
Optionally, The user can publish/push or "share" the like via x,y,z
networks.
Best,
Nathan
Chris Jackson
May 3, 2010, 10:26:47 AM5/3/10
to open...@googlegroups.com
The crucial difference between Jo's proposal and Kevin's demo is that
Kevin's demo requires the user to both be logged on to Facebook and to
authenticate via FB with the current site (what used to be caled
Facebook Connect), whereas the new Facebook Like button (and, by
extension, Jo's proposal) only requires
Facebook Connect to a new site is a pretty scary thing for a user.
We've seen drop-off rates comparable with a typical registration
process. I'd be fascinated to learn if there's a route to send like
information to Facebook and other sites without requiring a Facebook
Connect. This is key to the success of any open like initiative.
Chris
--
ch...@metabroadcast.com -- +44 7967 756705
Kevin's demo requires the user to both be logged on to Facebook and to
authenticate via FB with the current site (what used to be caled
Facebook Connect), whereas the new Facebook Like button (and, by
extension, Jo's proposal) only requires
Facebook Connect to a new site is a pretty scary thing for a user.
We've seen drop-off rates comparable with a typical registration
process. I'd be fascinated to learn if there's a route to send like
information to Facebook and other sites without requiring a Facebook
Connect. This is key to the success of any open like initiative.
Chris
ch...@metabroadcast.com -- +44 7967 756705
Chris Jackson
May 3, 2010, 10:30:05 AM5/3/10
to open...@googlegroups.com
On 3 May 2010 15:26, Chris Jackson <chr...@gmail.com> wrote:
> extension, Jo's proposal) only requires
the user to be logged on to Facebook
> extension, Jo's proposal) only requires
jopotts
May 3, 2010, 10:44:27 AM5/3/10
to OpenLike
@Chris - exactly! I'm not sure if it's possible to 'intercept' the
current facebook like plugin with javascript as I'm not a js guru.
However, I have checked and it is possible to get a user's facebook ID
simply by having the plugin on the page.
@Nathan - I think by removing the storage of the 'like' and simply
broadcasting the message, it's making it truly open. The whole point
of openlike is to somehow stop facebook's monopolisation of the person-
to-thing social graph. Keeping it simple and hooking into facebook's
existing like is crucial for publisher adoption.
current facebook like plugin with javascript as I'm not a js guru.
However, I have checked and it is possible to get a user's facebook ID
simply by having the plugin on the page.
@Nathan - I think by removing the storage of the 'like' and simply
broadcasting the message, it's making it truly open. The whole point
of openlike is to somehow stop facebook's monopolisation of the person-
to-thing social graph. Keeping it simple and hooking into facebook's
existing like is crucial for publisher adoption.
Kevin Marshall
May 3, 2010, 10:46:36 AM5/3/10
to open...@googlegroups.com
There's no incentive for facebook to not require the extra step...and
there's also no easy way for it to be technically possible (facebook
couldn't trust a middle man to post on someone's behalf unless that
someone has told them it's OK).
To me, the idea behind likefeature.com is to separate the process of
'liking' something and 'brodcasting' that like.
Facebook like (and all the other services currently included in
OpenLike) is a one stop shop for this, but it also means there's only
one way in and one way out (great for facebook, OK for most users,
fairly horrible for the actual website that implements the feature).
If I'm going to put a like button on my site, I want to be able to get
at the data my users supply in some easy fashion...and ideally, I want
my users to be able to share their data across any/all the networks
that they choose (not just facebook)...
At least, that was my working theory behind building likefeature.com
(which btw, is a pure hack simply to 'show' my point of view rather
than try to explain all the intricate details via message boards) :-)
- Kevin
http://www.likefeature.com
there's also no easy way for it to be technically possible (facebook
couldn't trust a middle man to post on someone's behalf unless that
someone has told them it's OK).
To me, the idea behind likefeature.com is to separate the process of
'liking' something and 'brodcasting' that like.
Facebook like (and all the other services currently included in
OpenLike) is a one stop shop for this, but it also means there's only
one way in and one way out (great for facebook, OK for most users,
fairly horrible for the actual website that implements the feature).
If I'm going to put a like button on my site, I want to be able to get
at the data my users supply in some easy fashion...and ideally, I want
my users to be able to share their data across any/all the networks
that they choose (not just facebook)...
At least, that was my working theory behind building likefeature.com
(which btw, is a pure hack simply to 'show' my point of view rather
than try to explain all the intricate details via message boards) :-)
- Kevin
http://www.likefeature.com
Kevin Marshall
May 3, 2010, 11:07:36 AM5/3/10
to open...@googlegroups.com
Sorry - a bit more detail on my thinking about why 'intercepting' is a
good direction that I wanted to share with the list for discussion:
Let's say you have a blog...if you put the facebook 'like' button on
your blog, users can come and 'like' a given post...that 'like' get's
broadcast out to their profile so their friends see it, but as the
blog writer, do you have any information about it? (you might, I
actually don't know -- hopefully facebook does give you some form of
reporting or something?)...if you don't get any sort of report or API
access to who's liking your stuff, you can't actually ask the user to
pull it back out (because you don't actually know what users 'liked'
your stuff.
This scenario stretches across all the 'service specific' like
features (for example Hunch's like has the same problem)...and this
speaks nothing to the idea of spreading a given 'like' across all of a
user's social platforms.
To me, there are a handful of problem scenarios that I'm hoping to
have solved (only some of which I envision an OpenLike or LikeFeature
are actually addressing):
1. As a publisher, I want to be able to get a list of people that
'liked' my stuff (at a min. tell me the service they auth'ed with,
what sentiment they gave my 'thing', and when they did it) -- for
example http://likefeature.com/v1/get/JSON/url/http%3A%2F%2Ffriendstat.us
tells me who's liked http://friendstat.us
2. As a publisher and/or as a developer, I would like to know what
else a user 'liked' - for example
http://likefeature.com/v1/get/twitter/falicon tells me what the
twitter user Falicon has liked across the web.
3. As a publisher I want my users to share their 'likes' across all
their social networks (because this drives more traffic back to
me)...currently this is a feature I don't think exists (though I'm
thinking it can be accomplished with a 'settings' feature on something
like likefeature.com where users specify which services to push their
sentiment back out to). Also, because the data store is open on
likefeature.com, any service can also write their own process for
pulling down/sync'ing a users likes as they wish.
4. As a user, I don't really care about my 'friends' seeing what I
like but I do expect/hope/assume that the publisher of the 'thing' I'm
liking gets my nod (I think of it as giving a non-monetary tip or
thank you).
Anyway those are some quick/random thoughts on my motivation for
LikeFeature.com (and why I was initially interested in the idea of
OpenLike.org).
- Kevin
http://pu.ly
On Mon, May 3, 2010 at 10:49 AM, Alex Iskold <alex....@gmail.com> wrote:
> What is the objective of intercepting?
>
> My understanding is that data can be fetched out of Facebook anytime
> with user permission.
>
> Also, I am unclear on what is the publisher benefit in this scenario?
> If we "backed-it" up for them to their own database, I can see why
> they
> would do it, but as is, I am not sure.
>
> And Facebook supports broadcast as well. If user gives you permission,
> then you can get notifications when new likes flow in.
>>
>> On Mon, May 3, 2010 at 10:30 AM, Chris Jackson <chri...@gmail.com> wrote:
good direction that I wanted to share with the list for discussion:
Let's say you have a blog...if you put the facebook 'like' button on
your blog, users can come and 'like' a given post...that 'like' get's
broadcast out to their profile so their friends see it, but as the
blog writer, do you have any information about it? (you might, I
actually don't know -- hopefully facebook does give you some form of
reporting or something?)...if you don't get any sort of report or API
access to who's liking your stuff, you can't actually ask the user to
pull it back out (because you don't actually know what users 'liked'
your stuff.
This scenario stretches across all the 'service specific' like
features (for example Hunch's like has the same problem)...and this
speaks nothing to the idea of spreading a given 'like' across all of a
user's social platforms.
To me, there are a handful of problem scenarios that I'm hoping to
have solved (only some of which I envision an OpenLike or LikeFeature
are actually addressing):
1. As a publisher, I want to be able to get a list of people that
'liked' my stuff (at a min. tell me the service they auth'ed with,
what sentiment they gave my 'thing', and when they did it) -- for
example http://likefeature.com/v1/get/JSON/url/http%3A%2F%2Ffriendstat.us
tells me who's liked http://friendstat.us
2. As a publisher and/or as a developer, I would like to know what
else a user 'liked' - for example
http://likefeature.com/v1/get/twitter/falicon tells me what the
twitter user Falicon has liked across the web.
3. As a publisher I want my users to share their 'likes' across all
their social networks (because this drives more traffic back to
me)...currently this is a feature I don't think exists (though I'm
thinking it can be accomplished with a 'settings' feature on something
like likefeature.com where users specify which services to push their
sentiment back out to). Also, because the data store is open on
likefeature.com, any service can also write their own process for
pulling down/sync'ing a users likes as they wish.
4. As a user, I don't really care about my 'friends' seeing what I
like but I do expect/hope/assume that the publisher of the 'thing' I'm
liking gets my nod (I think of it as giving a non-monetary tip or
thank you).
Anyway those are some quick/random thoughts on my motivation for
LikeFeature.com (and why I was initially interested in the idea of
OpenLike.org).
- Kevin
http://pu.ly
On Mon, May 3, 2010 at 10:49 AM, Alex Iskold <alex....@gmail.com> wrote:
> What is the objective of intercepting?
>
> My understanding is that data can be fetched out of Facebook anytime
> with user permission.
>
> Also, I am unclear on what is the publisher benefit in this scenario?
> If we "backed-it" up for them to their own database, I can see why
> they
> would do it, but as is, I am not sure.
>
> And Facebook supports broadcast as well. If user gives you permission,
> then you can get notifications when new likes flow in.
>
> On May 3, 10:46 am, Kevin Marshall <falico...@gmail.com> wrote:
>> There's no incentive for facebook to not require the extra step...and
>> there's also no easy way for it to be technically possible (facebook
>> couldn't trust a middle man to post on someone's behalf unless that
>> someone has told them it's OK).
>>
>> To me, the idea behind likefeature.com is to separate the process of
>> 'liking' something and 'brodcasting' that like.
>>
>> Facebook like (and all the other services currently included in
>> OpenLike) is a one stop shop for this, but it also means there's only
>> one way in and one way out (great for facebook, OK for most users,
>> fairly horrible for the actual website that implements the feature).
>>
>> If I'm going to put a like button on my site, I want to be able to get
>> at the data my users supply in some easy fashion...and ideally, I want
>> my users to be able to share their data across any/all the networks
>> that they choose (not just facebook)...
>>
>> At least, that was my working theory behind building likefeature.com
>> (which btw, is a pure hack simply to 'show' my point of view rather
>> than try to explain all the intricate details via message boards) :-)
>>
>> - Kevinhttp://www.likefeature.com
> On May 3, 10:46 am, Kevin Marshall <falico...@gmail.com> wrote:
>> There's no incentive for facebook to not require the extra step...and
>> there's also no easy way for it to be technically possible (facebook
>> couldn't trust a middle man to post on someone's behalf unless that
>> someone has told them it's OK).
>>
>> To me, the idea behind likefeature.com is to separate the process of
>> 'liking' something and 'brodcasting' that like.
>>
>> Facebook like (and all the other services currently included in
>> OpenLike) is a one stop shop for this, but it also means there's only
>> one way in and one way out (great for facebook, OK for most users,
>> fairly horrible for the actual website that implements the feature).
>>
>> If I'm going to put a like button on my site, I want to be able to get
>> at the data my users supply in some easy fashion...and ideally, I want
>> my users to be able to share their data across any/all the networks
>> that they choose (not just facebook)...
>>
>> At least, that was my working theory behind building likefeature.com
>> (which btw, is a pure hack simply to 'show' my point of view rather
>> than try to explain all the intricate details via message boards) :-)
>>
>>
>> On Mon, May 3, 2010 at 10:30 AM, Chris Jackson <chri...@gmail.com> wrote:
Kingsley Idehen
May 3, 2010, 12:05:44 PM5/3/10
to open...@googlegroups.com
data. Does Facebook broadcast or serve up data from "Thin Air" ?
Time and time again, we repeat the same mistakes re. data. You access
data from somehwere and put it somewhere. This you simply cannot negate
with any variant of code.
Plugins are fronts for code.
Code is about Data Manipulation.
Data lives somewhere.
Making silos via code or code snippets doesn't negate any of the items
above.
--
Regards,
Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
jopotts
May 3, 2010, 12:21:05 PM5/3/10
to OpenLike
I agree with everything you say Kevin. Thanks for the time spent
reiterating it all as I know you already said this in previous posts
*and* went and implemented the whole thing! :)
Publisher adoption is the main issue which is why I was thinking about
how to somehow keep facebook's like button but also siphon off the
sentiment for others to use. Technically though, having just looking
into it a bit, I don't think it's possible. Neither is it possible to
know a person's facebook ID without authenticating (as I thought
before). A shame.
My new thoughts are that openlike.org should now take on Kevin's
likefeature.com [idea] (moving from .com to .org is important) and
present it as a single broadcasting button. As a technical note, I
think the separation of the broadcast service and like database would
still be a good idea. This wouldn't prevent any of the points you make
Kevin.
reiterating it all as I know you already said this in previous posts
*and* went and implemented the whole thing! :)
Publisher adoption is the main issue which is why I was thinking about
how to somehow keep facebook's like button but also siphon off the
sentiment for others to use. Technically though, having just looking
into it a bit, I don't think it's possible. Neither is it possible to
know a person's facebook ID without authenticating (as I thought
before). A shame.
My new thoughts are that openlike.org should now take on Kevin's
likefeature.com [idea] (moving from .com to .org is important) and
present it as a single broadcasting button. As a technical note, I
think the separation of the broadcast service and like database would
still be a good idea. This wouldn't prevent any of the points you make
Kevin.
Kevin Marshall
May 3, 2010, 12:26:23 PM5/3/10
to open...@googlegroups.com
Hey that just might be the first time in my life someone's agreed with me! ;-)
Seriously though...I'm totally 'open' to the idea of moving the
likefeature concept to an 'org' and having it be true open source and
available for the masses (my existing code is probably not a great
starting point as it's pretty hackish...but happy to hand it over if
we get something set up and want to use it as a starting point).
- Kevin
http://grou.pe
Seriously though...I'm totally 'open' to the idea of moving the
likefeature concept to an 'org' and having it be true open source and
available for the masses (my existing code is probably not a great
starting point as it's pretty hackish...but happy to hand it over if
we get something set up and want to use it as a starting point).
- Kevin
http://grou.pe
Nathan
May 3, 2010, 12:36:58 PM5/3/10
to open...@googlegroups.com
jopotts wrote:
> I agree with everything you say Kevin. Thanks for the time spent
> reiterating it all as I know you already said this in previous posts
> *and* went and implemented the whole thing! :)
>
> Publisher adoption is the main issue which is why I was thinking about
> how to somehow keep facebook's like button but also siphon off the
> sentiment for others to use. Technically though, having just looking
> into it a bit, I don't think it's possible. Neither is it possible to
> know a person's facebook ID without authenticating (as I thought
> before). A shame.
after somebody authenticates and makes a "like" on facebook, could the
> I agree with everything you say Kevin. Thanks for the time spent
> reiterating it all as I know you already said this in previous posts
> *and* went and implemented the whole thing! :)
>
> Publisher adoption is the main issue which is why I was thinking about
> how to somehow keep facebook's like button but also siphon off the
> sentiment for others to use. Technically though, having just looking
> into it a bit, I don't think it's possible. Neither is it possible to
> know a person's facebook ID without authenticating (as I thought
> before). A shame.
app not subscribe/pull the like back from facebook - no need to do it
before surely?
Kevin Marshall
May 3, 2010, 12:44:31 PM5/3/10
to open...@googlegroups.com
> after somebody authenticates and makes a "like" on facebook, could the app not subscribe/pull the like back from facebook - no need to do it before surely?
Only if facebook has an API or gives the app some way of knowing about
the 'likes'...the current button has no interaction with the app
itself, so the app doesn't really know when someone clicks on it, who
clicked on it, or anything like that...all the app knows is that it's
told facebook (or whatever service) that people are allowed to 'like'
stuff at this given URL and the app shows them the button they can
click on...
As a side note, in addition to getting the data about who's liking
what, the service that provides this feature can also collect tons of
data about what pages are and are not getting viewed (it's basically a
functional version of compete's invis grafic, or google analytics or
chartbeat's javascript)...that's not bad data to be owning/collecting
either.
- Kevin
http://uridata.com
Chris Jackson
May 3, 2010, 12:48:01 PM5/3/10
to open...@googlegroups.com
user has connected with the app for your site then you can normally
get their likes back, too. But most users are reluctant to connect.
So, in most cases you can't find out **who** liked your content.
That's a big downside of the FB button vs. a cookie-based custom like
button, because it stops all kinds of helpful personalization. Of
course, FB provides lots of widgets for this stuff. So it's fine, if
you're happy to delegate personalization to them...
Hence, interception would be really helpful. It deserves some serious
tech and legal investigation.
Chris
Reply all
Reply to author
Forward
0 new messages