The opensocial people fetching is sorta limited right now. You can't fetch Bob's friends, only the VIEWER and OWNER friends. You also can't ask for the VIEWER's friends of friends or reference any other grouping mechanism. I propose that we address all of this somehow by changing either the idSpec type, the newFetchPeopleRequest call or some combination of the two.
Here is what we have right now:
- idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends -- not a real js object - newFetchPeopleRequest takes in an idSpec to tell it which people to fetch. - another wip proposal of 0.8 is to add the filter "isFriendsWith" and another idSpec that a person has to be friends with
Here is something we could do instead:
idSpec becomes a real object "opensocial.idSpec" with three fields: - userId - groupid - networkDistance (? - see below)
Containers could support additional groupIds, allowing opensocial to slowly add support for that type of functionality as well. We could also use a "networkDistance" field to idSpec which would then allow you to do friends of friends:
I'm not sure if the networkDistance makes sense for non FRIENDS groups though. (but we do get to move it out of the isFriendsWith filterOptions if we put it in the idSpec object as well)
The isFriendsWith filter still makes sense with this new object but it has more power. You can ask for the friends that bob and suzie both share:
Some of these requests could get extremely complicated, but each container will always be able to choose to support only what it wants to support. A container also always has the right to deny access to someone's data, group membership or anything else. I think this simply will make opensocial more flexible for those containers who really like network connections and support friends of friends and other such things.
Alright, so after all that, what do you think? And please chime in if you have a simpler yet just as flexible idea! Thanks.
This seems like a good simplification. Some additional ideas:
- We should consider creating having a call that just expands out an idSpec into a list of associated ID, let's say newFetchPersonIdsRequest() - Then all of the other calls could just take an array of user IDs or a reference to results of a newFetchPersonIdsRequest(). - We would add a newFetchProfilesRequest() to get profiles in this case - This works well in the case where you want to view profiles, app data, and possibly activities from the same set of people. Instead of having all of the API calls take an idSpec, we instead have them take an array of IDs or a reference to a newFetchPersonIdsRequest() call. This seems a bit cleaner. - I was going to say that we also want to support looking up multiple people by ID (i.e. currently we can have an array of IDs). However this use case works automatically if we separate idSpec expansion from other calls.
On Thu, Apr 3, 2008 at 9:52 AM, Cassie <d...@google.com> wrote:
> The opensocial people fetching is sorta limited right now. You can't > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't > ask for the VIEWER's friends of friends or reference any other > grouping mechanism. I propose that we address all of this somehow by > changing either the idSpec type, the newFetchPeopleRequest call or > some combination of the two.
> Here is what we have right now:
> - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends -- > not a real js object > - newFetchPeopleRequest takes in an idSpec to tell it which people to > fetch. > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and > another idSpec that a person has to be friends with
> Here is something we could do instead:
> idSpec becomes a real object "opensocial.idSpec" with three fields: > - userId > - groupid > - networkDistance (? - see below)
> Containers could support additional groupIds, allowing opensocial to > slowly add support for that type of functionality as well. We could > also use a "networkDistance" field to idSpec which would then allow > you to do friends of friends:
> I'm not sure if the networkDistance makes sense for non FRIENDS groups > though. > (but we do get to move it out of the isFriendsWith filterOptions if we > put it in the idSpec object as well)
> The isFriendsWith filter still makes sense with this new object but it > has more power. You can ask for the friends that bob and suzie both > share:
> Some of these requests could get extremely complicated, but each > container will always be able to choose to support only what it wants > to support. A container also always has the right to deny access to > someone's data, group membership or anything else. I think this simply > will make opensocial more flexible for those containers who really > like network connections and support friends of friends and other such > things.
> Alright, so after all that, what do you think? > And please chime in if you have a simpler yet just as flexible idea! > Thanks.
I would be against the idea of doing a 2-phase fetch of people as Evan suggested as it will limit the ability of containers to intelligently implement prefetching which largely relies on the use of tokens such as VIEWER, OWNER etc.. I think using the existing fetchPerson request and limiting the returned objects to their ID fields is equivalent functionality and already defined within the spec.
A couple of notes on distance. I believe as has been mentioned earlier that distance is 1 based not 0 based, so friend-of-friend is distance 2 not 1.
In the example below is networkDistance an inclusive (all relations where distance is <= <dist>) or excact (all relations where distance is = <dist>) predicate?
On Thu, Apr 3, 2008 at 10:58 AM, Evan Gilbert <uid...@google.com> wrote: > This seems like a good simplification. Some additional ideas:
> - We should consider creating having a call that just expands out an > idSpec into a list of associated ID, let's say newFetchPersonIdsRequest() > - Then all of the other calls could just take an array of user IDs > or a reference to results of a newFetchPersonIdsRequest(). > - We would add a newFetchProfilesRequest() to get profiles in > this case > - This works well in the case where you want to view profiles, > app data, and possibly activities from the same set of people. Instead of > having all of the API calls take an idSpec, we instead have them take an > array of IDs or a reference to a newFetchPersonIdsRequest() call. This seems > a bit cleaner. > - I was going to say that we also want to support looking up > multiple people by ID (i.e. currently we can have an array of IDs). However > this use case works automatically if we separate idSpec expansion from other > calls.
> Evan
> On Thu, Apr 3, 2008 at 9:52 AM, Cassie <d...@google.com> wrote:
> > The opensocial people fetching is sorta limited right now. You can't > > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't > > ask for the VIEWER's friends of friends or reference any other > > grouping mechanism. I propose that we address all of this somehow by > > changing either the idSpec type, the newFetchPeopleRequest call or > > some combination of the two.
> > Here is what we have right now:
> > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends -- > > not a real js object > > - newFetchPeopleRequest takes in an idSpec to tell it which people to > > fetch. > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and > > another idSpec that a person has to be friends with
> > Here is something we could do instead:
> > idSpec becomes a real object "opensocial.idSpec" with three fields: > > - userId > > - groupid > > - networkDistance (? - see below)
> > Containers could support additional groupIds, allowing opensocial to > > slowly add support for that type of functionality as well. We could > > also use a "networkDistance" field to idSpec which would then allow > > you to do friends of friends:
> > I'm not sure if the networkDistance makes sense for non FRIENDS groups > > though. > > (but we do get to move it out of the isFriendsWith filterOptions if we > > put it in the idSpec object as well)
> > The isFriendsWith filter still makes sense with this new object but it > > has more power. You can ask for the friends that bob and suzie both > > share:
> > Some of these requests could get extremely complicated, but each > > container will always be able to choose to support only what it wants > > to support. A container also always has the right to deny access to > > someone's data, group membership or anything else. I think this simply > > will make opensocial more flexible for those containers who really > > like network connections and support friends of friends and other such > > things.
> > Alright, so after all that, what do you think? > > And please chime in if you have a simpler yet just as flexible idea! > > Thanks.
Shoot - I thought I had gotten it right this time but I screwed it up again. You are correct, fof = 2 not 1.
Hmm... I'm sot sure whether it is inclusive. When you want to fetch someone's friend of a friends do you also want their friends? (Anybody writing gadgets have an opinion here?)
On Thu, Apr 3, 2008 at 8:50 PM, Louis Ryan <lr...@google.com> wrote: > I like the pattern.
> I would be against the idea of doing a 2-phase fetch of people as Evan > suggested as it will limit the ability of containers to intelligently > implement prefetching which largely relies on the use of tokens such as > VIEWER, OWNER etc.. I think using the existing fetchPerson request and > limiting the returned objects to their ID fields is equivalent functionality > and already defined within the spec.
> A couple of notes on distance. I believe as has been mentioned earlier that > distance is 1 based not 0 based, so friend-of-friend is distance 2 not 1.
> In the example below is networkDistance an inclusive (all relations where > distance is <= <dist>) or excact (all relations where distance is = <dist>) > predicate?
> On Thu, Apr 3, 2008 at 10:58 AM, Evan Gilbert <uid...@google.com> wrote: > > This seems like a good simplification. Some additional ideas:
> > We should consider creating having a call that just expands out an idSpec > into a list of associated ID, let's say newFetchPersonIdsRequest()
> > Then all of the other calls could just take an array of user IDs or a > reference to results of a newFetchPersonIdsRequest(). > > We would add a newFetchProfilesRequest() to get profiles in this case > > This works well in the case where you want to view profiles, app data, and > possibly activities from the same set of people. Instead of having all of > the API calls take an idSpec, we instead have them take an array of IDs or a > reference to a newFetchPersonIdsRequest() call. This seems a bit cleaner.
> > I was going to say that we also want to support looking up multiple people > by ID (i.e. currently we can have an array of IDs). However this use case > works automatically if we separate idSpec expansion from other calls. Evan
> > On Thu, Apr 3, 2008 at 9:52 AM, Cassie <d...@google.com> wrote:
> > > The opensocial people fetching is sorta limited right now. You can't > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't > > > ask for the VIEWER's friends of friends or reference any other > > > grouping mechanism. I propose that we address all of this somehow by > > > changing either the idSpec type, the newFetchPeopleRequest call or > > > some combination of the two.
> > > Here is what we have right now:
> > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends -- > > > not a real js object > > > - newFetchPeopleRequest takes in an idSpec to tell it which people to > fetch. > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and > > > another idSpec that a person has to be friends with
> > > Here is something we could do instead:
> > > idSpec becomes a real object "opensocial.idSpec" with three fields: > > > - userId > > > - groupid > > > - networkDistance (? - see below)
> > > This would change the old idSpecs as follows:
> > > Containers could support additional groupIds, allowing opensocial to > > > slowly add support for that type of functionality as well. We could > > > also use a "networkDistance" field to idSpec which would then allow > > > you to do friends of friends:
> > > I'm not sure if the networkDistance makes sense for non FRIENDS groups > though. > > > (but we do get to move it out of the isFriendsWith filterOptions if we > > > put it in the idSpec object as well)
> > > The isFriendsWith filter still makes sense with this new object but it > > > has more power. You can ask for the friends that bob and suzie both > > > share:
> > > Some of these requests could get extremely complicated, but each > > > container will always be able to choose to support only what it wants > > > to support. A container also always has the right to deny access to > > > someone's data, group membership or anything else. I think this simply > > > will make opensocial more flexible for those containers who really > > > like network connections and support friends of friends and other such > > > things.
> > > Alright, so after all that, what do you think? > > > And please chime in if you have a simpler yet just as flexible idea! > > > Thanks.
I am wondering if application developers really want to use friend's friend list fetching functionality. Container developers either. I can't imagine any cases where app developers need to use the list except for spam purpose.
Say if you have 100 friends who have 100 friends each. It's gonna be list of 10,000 people which seems to be a good load both on client side and server side.
Practical use case I can imagine for something like this is for example, an app that shares user's photo for the network distance of 2. It's not general to use real name for social network sites in Japan, that if you want your friend(who is not in relationship yet) to find you, you may want to share your picture to friend's friend distance.
The point is, the API app developer need is to see if the VIEWER is friend's friend of the OWNER. Not the whole list of friend's friend.
> Shoot - I thought I had gotten it right this time but I screwed it up > again. You are correct, fof = 2 not 1.
> Hmm... I'm sot sure whether it is inclusive. When you want to fetch > someone's friend of a friends do you also want their friends? (Anybody > writing gadgets have an opinion here?)
> - Cassie
> On Thu, Apr 3, 2008 at 8:50 PM, Louis Ryan <lr...@google.com> wrote: > > I like the pattern.
> > I would be against the idea of doing a 2-phase fetch of people as Evan > > suggested as it will limit the ability of containers to intelligently > > implement prefetching which largely relies on the use of tokens such as > > VIEWER, OWNER etc.. I think using the existing fetchPerson request and > > limiting the returned objects to their ID fields is equivalent functionality > > and already defined within the spec.
> > A couple of notes on distance. I believe as has been mentioned earlier that > > distance is 1 based not 0 based, so friend-of-friend is distance 2 not 1.
> > In the example below is networkDistance an inclusive (all relations where > > distance is <= <dist>) or excact (all relations where distance is = <dist>) > > predicate?
> > On Thu, Apr 3, 2008 at 10:58 AM, Evan Gilbert <uid...@google.com> wrote: > > > This seems like a good simplification. Some additional ideas:
> > > We should consider creating having a call that just expands out an idSpec > > into a list of associated ID, let's say newFetchPersonIdsRequest()
> > > Then all of the other calls could just take an array of user IDs or a > > reference to results of a newFetchPersonIdsRequest(). > > > We would add a newFetchProfilesRequest() to get profiles in this case > > > This works well in the case where you want to view profiles, app data, and > > possibly activities from the same set of people. Instead of having all of > > the API calls take an idSpec, we instead have them take an array of IDs or a > > reference to a newFetchPersonIdsRequest() call. This seems a bit cleaner.
> > > I was going to say that we also want to support looking up multiple people > > by ID (i.e. currently we can have an array of IDs). However this use case > > works automatically if we separate idSpec expansion from other calls. Evan
> > > On Thu, Apr 3, 2008 at 9:52 AM, Cassie <d...@google.com> wrote:
> > > > The opensocial people fetching is sorta limited right now. You can't > > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't > > > > ask for the VIEWER's friends of friends or reference any other > > > > grouping mechanism. I propose that we address all of this somehow by > > > > changing either the idSpec type, the newFetchPeopleRequest call or > > > > some combination of the two.
> > > > Here is what we have right now:
> > > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends -- > > > > not a real js object > > > > - newFetchPeopleRequest takes in an idSpec to tell it which people to > > fetch. > > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and > > > > another idSpec that a person has to be friends with
> > > > Here is something we could do instead:
> > > > idSpec becomes a real object "opensocial.idSpec" with three fields: > > > > - userId > > > > - groupid > > > > - networkDistance (? - see below)
> > > > This would change the old idSpecs as follows:
> > > > Containers could support additional groupIds, allowing opensocial to > > > > slowly add support for that type of functionality as well. We could > > > > also use a "networkDistance" field to idSpec which would then allow > > > > you to do friends of friends:
> > > > I'm not sure if the networkDistance makes sense for non FRIENDS groups > > though. > > > > (but we do get to move it out of the isFriendsWith filterOptions if we > > > > put it in the idSpec object as well)
> > > > The isFriendsWith filter still makes sense with this new object but it > > > > has more power. You can ask for the friends that bob and suzie both > > > > share:
> > > > Some of these requests could get extremely complicated, but each > > > > container will always be able to choose to support only what it wants > > > > to support. A container also always has the right to deny access to > > > > someone's data, group membership or anything else. I think this simply > > > > will make opensocial more flexible for those containers who really > > > > like network connections and support friends of friends and other such > > > > things.
> > > > Alright, so after all that, what do you think? > > > > And please chime in if you have a simpler yet just as flexible idea! > > > > Thanks.
I agree that just plainly asking for a second degree network doesn't make sense; my Hyves 2nd degree network is 80k+ people, and I'm not a huge friend-collector by far. It would only make sense in combination with meaningful filters, or limits and order-by's: - - Give me all 2nd degree friends that have the app installed - - Give me all 2nd degree friends who have updated their presence in the last 10 minutes - - Give me the 100 2nd degree friends with the most pictures
Problem is that these calls can only be served efficiently by the container if it is optimized for it. In practice this will mean that many containers will not support these features.
I like making the syntax available for containers that support them, while not requiring any support.
> I am wondering if application developers really want to use friend's > friend list fetching functionality. Container developers either. > I can't imagine any cases where app developers need to use the list > except for spam purpose.
> Say if you have 100 friends who have 100 friends each. It's gonna be > list of 10,000 people which seems to be a good load both on client > side and server side.
> Practical use case I can imagine for something like this is for > example, an app that shares user's photo for the network distance of > 2. It's not general to use real name for social network sites in > Japan, that if you want your friend(who is not in relationship yet) to > find you, you may want to share your picture to friend's friend > distance.
> The point is, the API app developer need is to see if the VIEWER is > friend's friend of the OWNER. Not the whole list of friend's friend.
> What do others think?
> 2008/4/4, Cassie <d...@google.com>: >> Shoot - I thought I had gotten it right this time but I screwed it up >> again. You are correct, fof = 2 not 1.
>> Hmm... I'm sot sure whether it is inclusive. When you want to fetch >> someone's friend of a friends do you also want their friends? (Anybody >> writing gadgets have an opinion here?)
>> - Cassie
>> On Thu, Apr 3, 2008 at 8:50 PM, Louis Ryan <lr...@google.com> wrote: >> > I like the pattern.
>> > I would be against the idea of doing a 2-phase fetch of people as Evan >> > suggested as it will limit the ability of containers to intelligently >> > implement prefetching which largely relies on the use of tokens such as >> > VIEWER, OWNER etc.. I think using the existing fetchPerson request and >> > limiting the returned objects to their ID fields is equivalent functionality >> > and already defined within the spec.
>> > A couple of notes on distance. I believe as has been mentioned earlier that >> > distance is 1 based not 0 based, so friend-of-friend is distance 2 not 1.
>> > In the example below is networkDistance an inclusive (all relations where >> > distance is <= <dist>) or excact (all relations where distance is = <dist>) >> > predicate?
>> > On Thu, Apr 3, 2008 at 10:58 AM, Evan Gilbert <uid...@google.com> wrote: >> > > This seems like a good simplification. Some additional ideas:
>> > > We should consider creating having a call that just expands out an idSpec >> > into a list of associated ID, let's say newFetchPersonIdsRequest()
>> > > Then all of the other calls could just take an array of user IDs or a >> > reference to results of a newFetchPersonIdsRequest(). >> > > We would add a newFetchProfilesRequest() to get profiles in this case >> > > This works well in the case where you want to view profiles, app data, and >> > possibly activities from the same set of people. Instead of having all of >> > the API calls take an idSpec, we instead have them take an array of IDs or a >> > reference to a newFetchPersonIdsRequest() call. This seems a bit cleaner.
>> > > I was going to say that we also want to support looking up multiple people >> > by ID (i.e. currently we can have an array of IDs). However this use case >> > works automatically if we separate idSpec expansion from other calls. Evan
>> > > On Thu, Apr 3, 2008 at 9:52 AM, Cassie <d...@google.com> wrote:
>> > > > The opensocial people fetching is sorta limited right now. You can't >> > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't >> > > > ask for the VIEWER's friends of friends or reference any other >> > > > grouping mechanism. I propose that we address all of this somehow by >> > > > changing either the idSpec type, the newFetchPeopleRequest call or >> > > > some combination of the two.
>> > > > Here is what we have right now:
>> > > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends -- >> > > > not a real js object >> > > > - newFetchPeopleRequest takes in an idSpec to tell it which people to >> > fetch. >> > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and >> > > > another idSpec that a person has to be friends with
>> > > > Here is something we could do instead:
>> > > > idSpec becomes a real object "opensocial.idSpec" with three fields: >> > > > - userId >> > > > - groupid >> > > > - networkDistance (? - see below)
>> > > > This would change the old idSpecs as follows:
>> > > > Containers could support additional groupIds, allowing opensocial to >> > > > slowly add support for that type of functionality as well. We could >> > > > also use a "networkDistance" field to idSpec which would then allow >> > > > you to do friends of friends:
>> > > > I'm not sure if the networkDistance makes sense for non FRIENDS groups >> > though. >> > > > (but we do get to move it out of the isFriendsWith filterOptions if we >> > > > put it in the idSpec object as well)
>> > > > The isFriendsWith filter still makes sense with this new object but it >> > > > has more power. You can ask for the friends that bob and suzie both >> > > > share:
>> > > > Some of these requests could get extremely complicated, but each >> > > > container will always be able to choose to support only what it wants >> > > > to support. A container also always has the right to deny access to >> > > > someone's data, group membership or anything else. I think this simply >> > > > will make opensocial more flexible for those containers who really >> > > > like network connections and support friends of friends and other such >> > > > things.
>> > > > Alright, so after all that, what do you think? >> > > > And please chime in if you have a simpler yet just as flexible idea! >> > > > Thanks.
>> > > > - Cassie
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Eiji - There is a filtering by friends proposal already on the table here: http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm... You use the idSpec in conjunction with other things in order to produce meaningful results. One such call would be get all viewer's fofs that are friends with the owner (or vice versa)
Reinoud - I definitely agree with what you said. This syntax wouldn't make sense without filters, which is why containers can always deny any request they don't want to fulfill.
So overall it looks like Louis and Reinoud think this is okay, Eiji is on the fence and Evan had a different idea. Evan and others, should we move forward with the following spec change or go another route?
On Fri, Apr 4, 2008 at 3:48 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> I agree that just plainly asking for a second degree network doesn't > make sense; my Hyves 2nd degree network is 80k+ people, and I'm not a > huge friend-collector by far. It would only make sense in combination > with meaningful filters, or limits and order-by's: > - - Give me all 2nd degree friends that have the app installed > - - Give me all 2nd degree friends who have updated their presence in the > last 10 minutes > - - Give me the 100 2nd degree friends with the most pictures
> Problem is that these calls can only be served efficiently by the > container if it is optimized for it. In practice this will mean that > many containers will not support these features.
> I like making the syntax available for containers that support them, > while not requiring any support.
> Eiji Kitamura wrote: >> Hi,
>> I am wondering if application developers really want to use friend's >> friend list fetching functionality. Container developers either. >> I can't imagine any cases where app developers need to use the list >> except for spam purpose.
>> Say if you have 100 friends who have 100 friends each. It's gonna be >> list of 10,000 people which seems to be a good load both on client >> side and server side.
>> Practical use case I can imagine for something like this is for >> example, an app that shares user's photo for the network distance of >> 2. It's not general to use real name for social network sites in >> Japan, that if you want your friend(who is not in relationship yet) to >> find you, you may want to share your picture to friend's friend >> distance.
>> The point is, the API app developer need is to see if the VIEWER is >> friend's friend of the OWNER. Not the whole list of friend's friend.
>> What do others think?
>> 2008/4/4, Cassie <d...@google.com>: >>> Shoot - I thought I had gotten it right this time but I screwed it up >>> again. You are correct, fof = 2 not 1.
>>> Hmm... I'm sot sure whether it is inclusive. When you want to fetch >>> someone's friend of a friends do you also want their friends? (Anybody >>> writing gadgets have an opinion here?)
>>> - Cassie
>>> On Thu, Apr 3, 2008 at 8:50 PM, Louis Ryan <lr...@google.com> wrote: >>> > I like the pattern.
>>> > I would be against the idea of doing a 2-phase fetch of people as Evan >>> > suggested as it will limit the ability of containers to intelligently >>> > implement prefetching which largely relies on the use of tokens such as >>> > VIEWER, OWNER etc.. I think using the existing fetchPerson request and >>> > limiting the returned objects to their ID fields is equivalent functionality >>> > and already defined within the spec.
>>> > A couple of notes on distance. I believe as has been mentioned earlier that >>> > distance is 1 based not 0 based, so friend-of-friend is distance 2 not 1.
>>> > In the example below is networkDistance an inclusive (all relations where >>> > distance is <= <dist>) or excact (all relations where distance is = <dist>) >>> > predicate?
>>> > On Thu, Apr 3, 2008 at 10:58 AM, Evan Gilbert <uid...@google.com> wrote: >>> > > This seems like a good simplification. Some additional ideas:
>>> > > We should consider creating having a call that just expands out an idSpec >>> > into a list of associated ID, let's say newFetchPersonIdsRequest()
>>> > > Then all of the other calls could just take an array of user IDs or a >>> > reference to results of a newFetchPersonIdsRequest(). >>> > > We would add a newFetchProfilesRequest() to get profiles in this case >>> > > This works well in the case where you want to view profiles, app data, and >>> > possibly activities from the same set of people. Instead of having all of >>> > the API calls take an idSpec, we instead have them take an array of IDs or a >>> > reference to a newFetchPersonIdsRequest() call. This seems a bit cleaner.
>>> > > I was going to say that we also want to support looking up multiple people >>> > by ID (i.e. currently we can have an array of IDs). However this use case >>> > works automatically if we separate idSpec expansion from other calls. Evan
>>> > > On Thu, Apr 3, 2008 at 9:52 AM, Cassie <d...@google.com> wrote:
>>> > > > The opensocial people fetching is sorta limited right now. You can't >>> > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't >>> > > > ask for the VIEWER's friends of friends or reference any other >>> > > > grouping mechanism. I propose that we address all of this somehow by >>> > > > changing either the idSpec type, the newFetchPeopleRequest call or >>> > > > some combination of the two.
>>> > > > Here is what we have right now:
>>> > > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends -- >>> > > > not a real js object >>> > > > - newFetchPeopleRequest takes in an idSpec to tell it which people to >>> > fetch. >>> > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and >>> > > > another idSpec that a person has to be friends with
>>> > > > Here is something we could do instead:
>>> > > > idSpec becomes a real object "opensocial.idSpec" with three fields: >>> > > > - userId >>> > > > - groupid >>> > > > - networkDistance (? - see below)
>>> > > > This would change the old idSpecs as follows:
>>> > > > Containers could support additional groupIds, allowing opensocial to >>> > > > slowly add support for that type of functionality as well. We could >>> > > > also use a "networkDistance" field to idSpec which would then allow >>> > > > you to do friends of friends:
>>> > > > I'm not sure if the networkDistance makes sense for non FRIENDS groups >>> > though. >>> > > > (but we do get to move it out of the isFriendsWith filterOptions if we >>> > > > put it in the idSpec object as well)
>>> > > > The isFriendsWith filter still makes sense with this new object but it >>> > > > has more power. You can ask for the friends that bob and suzie both >>> > > > share:
>>> > > > Some of these requests could get extremely complicated, but each >>> > > > container will always be able to choose to support only what it wants >>> > > > to support. A container also always has the right to deny access to >>> > > > someone's data, group membership or anything else. I think this simply >>> > > > will make opensocial more flexible for those containers who really >>> > > > like network connections and support friends of friends and other such >>> > > > things.
>>> > > > Alright, so after all that, what do you think? >>> > > > And please chime in if you have a simpler yet just as flexible idea! >>> > > > Thanks.
>>> > > > - Cassie
> -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Is there not a more fundamental problem that the 2nd degree friends
never has given permission to share all the data to the outside world?
I can imagine I'm a friend of person A
and person A is a friend of Person B'
But I really don't like person B' and I have rejected his friend
request.
Are we not exposing my information to Person B' (indirectly through
Person A)
I think there is a privacy issue here, unless all the data information
is set to public.
On Apr 3, 9:52 am, Cassie <d...@google.com> wrote:
> The opensocial people fetching is sorta limited right now. You can't
> fetch Bob's friends, only the VIEWER and OWNER friends. You also can't
> ask for the VIEWER's friends of friends or reference any other
> grouping mechanism. I propose that we address all of this somehow by
> changing either the idSpec type, the newFetchPeopleRequest call or
> some combination of the two.
> Here is what we have right now:
> - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends --
> not a real js object
> - newFetchPeopleRequest takes in an idSpec to tell it which people to fetch.
> - another wip proposal of 0.8 is to add the filter "isFriendsWith" and
> another idSpec that a person has to be friends with
> Here is something we could do instead:
> idSpec becomes a real object "opensocial.idSpec" with three fields:
> - userId
> - groupid
> - networkDistance (? - see below)
> Containers could support additional groupIds, allowing opensocial to
> slowly add support for that type of functionality as well. We could
> also use a "networkDistance" field to idSpec which would then allow
> you to do friends of friends:
> I'm not sure if the networkDistance makes sense for non FRIENDS groups though.
> (but we do get to move it out of the isFriendsWith filterOptions if we
> put it in the idSpec object as well)
> The isFriendsWith filter still makes sense with this new object but it
> has more power. You can ask for the friends that bob and suzie both
> share:
> Some of these requests could get extremely complicated, but each
> container will always be able to choose to support only what it wants
> to support. A container also always has the right to deny access to
> someone's data, group membership or anything else. I think this simply
> will make opensocial more flexible for those containers who really
> like network connections and support friends of friends and other such
> things.
> Alright, so after all that, what do you think?
> And please chime in if you have a simpler yet just as flexible idea!
> Thanks.
These policies are obviously up to the container, but I would imagine that no container should expose data in this case that the viewer does not have access to through some other channel. The same obviously is true for owner: the viewer should never be able to get more information from the owner than the privacy settings allow. Whether the same is true the other way round is a more difficult question: Is the applications, that might be acting on behalf of the owner, allowed to get more information from the viewer than the owner himself could? However, this again is a question the containers need to solve for themselves.
On Mon, Apr 21, 2008 at 7:45 PM, Marco <ens...@gmail.com> wrote:
> Is there not a more fundamental problem that the 2nd degree friends > never has given permission to share all the data to the outside world? > I can imagine I'm a friend of person A > and person A is a friend of Person B' > But I really don't like person B' and I have rejected his friend > request.
> Are we not exposing my information to Person B' (indirectly through > Person A)
> I think there is a privacy issue here, unless all the data information > is set to public.
> On Apr 3, 9:52 am, Cassie <d...@google.com> wrote: > > The opensocial people fetching is sorta limited right now. You can't > > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't > > ask for the VIEWER's friends of friends or reference any other > > grouping mechanism. I propose that we address all of this somehow by > > changing either the idSpec type, the newFetchPeopleRequest call or > > some combination of the two.
> > Here is what we have right now:
> > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends -- > > not a real js object > > - newFetchPeopleRequest takes in an idSpec to tell it which people to > fetch. > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and > > another idSpec that a person has to be friends with
> > Here is something we could do instead:
> > idSpec becomes a real object "opensocial.idSpec" with three fields: > > - userId > > - groupid > > - networkDistance (? - see below)
> > Containers could support additional groupIds, allowing opensocial to > > slowly add support for that type of functionality as well. We could > > also use a "networkDistance" field to idSpec which would then allow > > you to do friends of friends:
> > I'm not sure if the networkDistance makes sense for non FRIENDS groups > though. > > (but we do get to move it out of the isFriendsWith filterOptions if we > > put it in the idSpec object as well)
> > The isFriendsWith filter still makes sense with this new object but it > > has more power. You can ask for the friends that bob and suzie both > > share:
> > Some of these requests could get extremely complicated, but each > > container will always be able to choose to support only what it wants > > to support. A container also always has the right to deny access to > > someone's data, group membership or anything else. I think this simply > > will make opensocial more flexible for those containers who really > > like network connections and support friends of friends and other such > > things.
> > Alright, so after all that, what do you think? > > And please chime in if you have a simpler yet just as flexible idea! > > Thanks.
I missed the spec opensocial.DataRequest.PeopleRequestFields which you
can specify how many and from which index you want to fetch people
collection.
Now it's clear and I have no objection with this proposal.
On Apr 14, 8:51 pm, Cassie <d...@google.com> wrote:
> Eiji - There is a filtering by friends proposal already on the table here:http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm...
> You use the idSpec in conjunction with other things in order to
> produce meaningful results. One such call would be get all viewer's
> fofs that are friends with the owner (or vice versa)
> Reinoud - I definitely agree with what you said. This syntax wouldn't
> make sense without filters, which is why containers can always deny
> any request they don't want to fulfill.
> So overall it looks like Louis and Reinoud think this is okay, Eiji is
> on the fence and Evan had a different idea. Evan and others, should we
> move forward with the following spec change or go another route?
> 2. Change all IdSpec references to be opensocial.IdSpec
> 3. Change the filtering proposal to get rid of the networkDistance
> param as it is now within the idSpec
> Thanks.
> - Cassie
> On Fri, Apr 4, 2008 at 3:48 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > I agree that just plainly asking for a second degree network doesn't
> > make sense; my Hyves 2nd degree network is 80k+ people, and I'm not a
> > huge friend-collector by far. It would only make sense in combination
> > with meaningful filters, or limits and order-by's:
> > - - Give me all 2nd degree friends that have the app installed
> > - - Give me all 2nd degree friends who have updated their presence in the
> > last 10 minutes
> > - - Give me the 100 2nd degree friends with the most pictures
> > Problem is that these calls can only be served efficiently by the
> > container if it is optimized for it. In practice this will mean that
> > many containers will not support these features.
> > I like making the syntax available for containers that support them,
> > while not requiring any support.
> > Eiji Kitamura wrote:
> >> Hi,
> >> I am wondering if application developers really want to use friend's
> >> friend list fetching functionality. Container developers either.
> >> I can't imagine any cases where app developers need to use the list
> >> except for spam purpose.
> >> Say if you have 100 friends who have 100 friends each. It's gonna be
> >> list of 10,000 people which seems to be a good load both on client
> >> side and server side.
> >> Practical use case I can imagine for something like this is for
> >> example, an app that shares user's photo for the network distance of
> >> 2. It's not general to use real name for social network sites in
> >> Japan, that if you want your friend(who is not in relationship yet) to
> >> find you, you may want to share your picture to friend's friend
> >> distance.
> >> The point is, the API app developer need is to see if the VIEWER is
> >> friend's friend of the OWNER. Not the whole list of friend's friend.
> >> What do others think?
> >> 2008/4/4, Cassie <d...@google.com>:
> >>> Shoot - I thought I had gotten it right this time but I screwed it up
> >>> again. You are correct, fof = 2 not 1.
> >>> Hmm... I'm sot sure whether it is inclusive. When you want to fetch
> >>> someone's friend of a friends do you also want their friends? (Anybody
> >>> writing gadgets have an opinion here?)
> >>> - Cassie
> >>> On Thu, Apr 3, 2008 at 8:50 PM, Louis Ryan <lr...@google.com> wrote:
> >>> > I like the pattern.
> >>> > I would be against the idea of doing a 2-phase fetch of people as Evan
> >>> > suggested as it will limit the ability of containers to intelligently
> >>> > implement prefetching which largely relies on the use of tokens such as
> >>> > VIEWER, OWNER etc.. I think using the existing fetchPerson request and
> >>> > limiting the returned objects to their ID fields is equivalent functionality
> >>> > and already defined within the spec.
> >>> > A couple of notes on distance. I believe as has been mentioned earlier that
> >>> > distance is 1 based not 0 based, so friend-of-friend is distance 2 not 1.
> >>> > In the example below is networkDistance an inclusive (all relations where
> >>> > distance is <= <dist>) or excact (all relations where distance is = <dist>)
> >>> > predicate?
> >>> > On Thu, Apr 3, 2008 at 10:58 AM, Evan Gilbert <uid...@google.com> wrote:
> >>> > > This seems like a good simplification. Some additional ideas:
> >>> > > We should consider creating having a call that just expands out an idSpec
> >>> > into a list of associated ID, let's say newFetchPersonIdsRequest()
> >>> > > Then all of the other calls could just take an array of user IDs or a
> >>> > reference to results of a newFetchPersonIdsRequest().
> >>> > > We would add a newFetchProfilesRequest() to get profiles in this case
> >>> > > This works well in the case where you want to view profiles, app data, and
> >>> > possibly activities from the same set of people. Instead of having all of
> >>> > the API calls take an idSpec, we instead have them take an array of IDs or a
> >>> > reference to a newFetchPersonIdsRequest() call. This seems a bit cleaner.
> >>> > > I was going to say that we also want to support looking up multiple people
> >>> > by ID (i.e. currently we can have an array of IDs). However this use case
> >>> > works automatically if we separate idSpec expansion from other calls. Evan
> >>> > > On Thu, Apr 3, 2008 at 9:52 AM, Cassie <d...@google.com> wrote:
> >>> > > > The opensocial people fetching is sorta limited right now. You can't
> >>> > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't
> >>> > > > ask for the VIEWER's friends of friends or reference any other
> >>> > > > grouping mechanism. I propose that we address all of this somehow by
> >>> > > > changing either the idSpec type, the newFetchPeopleRequest call or
> >>> > > > some combination of the two.
> >>> > > > Here is what we have right now:
> >>> > > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends --
> >>> > > > not a real js object
> >>> > > > - newFetchPeopleRequest takes in an idSpec to tell it which people to
> >>> > fetch.
> >>> > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and
> >>> > > > another idSpec that a person has to be friends with
> >>> > > > Here is something we could do instead:
> >>> > > > idSpec becomes a real object "opensocial.idSpec" with three fields:
> >>> > > > - userId
> >>> > > > - groupid
> >>> > > > - networkDistance (? - see below)
> >>> > > > This would change the old idSpecs as follows:
> >>> > > > Containers could support additional groupIds, allowing opensocial to
> >>> > > > slowly add support for that type of functionality as well. We could
> >>> > > > also use a "networkDistance" field to idSpec which would then allow
> >>> > > > you to do friends of friends:
> >>> > > > I'm not sure if the networkDistance makes sense for non FRIENDS groups
> >>> > though.
> >>> > > > (but we do get to move it out of the isFriendsWith filterOptions if we
> >>> > > > put it in the idSpec object as well)
> >>> > > > The isFriendsWith filter still makes sense with this new object but it
> >>> > > > has more power. You can ask for the friends that bob and suzie both
> >>> > > > share:
> >>> > > > Some of these requests could get extremely complicated, but each
> >>> > > > container will always be able to choose to support only what it wants
> >>> > > > to support. A container also always has the right to deny access to
> >>> > > > someone's data, group membership or anything else. I think this simply
> >>> > > > will make opensocial more flexible for those containers who really
> >>> > > > like network connections and support friends of friends and other such
> >>> > > > things.
> >>> > > > Alright, so after all that, what do you think?
> >>> > > > And please chime in if you have a simpler yet just as flexible idea!
> >>> > > > Thanks.
> >>> > > > - Cassie
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org
> These policies are obviously up to the container, but I would imagine that
> no container should expose data in this case that the viewer does not have
> access to through some other channel. The same obviously is true for owner:
> the viewer should never be able to get more information from the owner than
> the privacy settings allow. Whether the same is true the other way round is
> a more difficult question:
> Is the applications, that might be acting on behalf of the owner, allowed to
> get more information from the viewer than the owner himself could? However,
> this again is a question the containers need to solve for themselves.
> On Mon, Apr 21, 2008 at 7:45 PM, Marco <ens...@gmail.com> wrote:
> > Is there not a more fundamental problem that the 2nd degree friends
> > never has given permission to share all the data to the outside world?
> > I can imagine I'm a friend of person A
> > and person A is a friend of Person B'
> > But I really don't like person B' and I have rejected his friend
> > request.
> > Are we not exposing my information to Person B' (indirectly through
> > Person A)
> > I think there is a privacy issue here, unless all the data information
> > is set to public.
> > On Apr 3, 9:52 am, Cassie <d...@google.com> wrote:
> > > The opensocial people fetching is sorta limited right now. You can't
> > > fetch Bob's friends, only the VIEWER and OWNER friends. You also can't
> > > ask for the VIEWER's friends of friends or reference any other
> > > grouping mechanism. I propose that we address all of this somehow by
> > > changing either the idSpec type, the newFetchPeopleRequest call or
> > > some combination of the two.
> > > Here is what we have right now:
> > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends --
> > > not a real js object
> > > - newFetchPeopleRequest takes in an idSpec to tell it which people to
> > fetch.
> > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" and
> > > another idSpec that a person has to be friends with
> > > Here is something we could do instead:
> > > idSpec becomes a real object "opensocial.idSpec" with three fields:
> > > - userId
> > > - groupid
> > > - networkDistance (? - see below)
> > > This would change the old idSpecs as follows:
> > > Containers could support additional groupIds, allowing opensocial to
> > > slowly add support for that type of functionality as well. We could
> > > also use a "networkDistance" field to idSpec which would then allow
> > > you to do friends of friends:
> > > I'm not sure if the networkDistance makes sense for non FRIENDS groups
> > though.
> > > (but we do get to move it out of the isFriendsWith filterOptions if we
> > > put it in the idSpec object as well)
> > > The isFriendsWith filter still makes sense with this new object but it
> > > has more power. You can ask for the friends that bob and suzie both
> > > share:
> > > Some of these requests could get extremely complicated, but each
> > > container will always be able to choose to support only what it wants
> > > to support. A container also always has the right to deny access to
> > > someone's data, group membership or anything else. I think this simply
> > > will make opensocial more flexible for those containers who really
> > > like network connections and support friends of friends and other such
> > > things.
> > > Alright, so after all that, what do you think?
> > > And please chime in if you have a simpler yet just as flexible idea!
> > > Thanks.
On Tue, Apr 22, 2008 at 6:50 PM, Marco <ens...@gmail.com> wrote:
> Ok I can see the benefits as well. Let's make the NETWORK_DISTANCE > feature optional for the container.
It's up to the container whether they want to support any NETWORK_DISTANCE above N. In the case than N=1, the container does not support 2nd degree networks at all, effectively making support for the NETWORK_DISTANCE parameter optional.
> On Apr 22, 2:49 am, "Reinoud Elhorst" <rein...@hyves.nl> wrote: > > These policies are obviously up to the container, but I would imagine > that > > no container should expose data in this case that the viewer does not > have > > access to through some other channel. The same obviously is true for > owner: > > the viewer should never be able to get more information from the owner > than > > the privacy settings allow. Whether the same is true the other way round > is > > a more difficult question: > > Is the applications, that might be acting on behalf of the owner, > allowed to > > get more information from the viewer than the owner himself could? > However, > > this again is a question the containers need to solve for themselves.
> > On Mon, Apr 21, 2008 at 7:45 PM, Marco <ens...@gmail.com> wrote:
> > > Is there not a more fundamental problem that the 2nd degree friends > > > never has given permission to share all the data to the outside world? > > > I can imagine I'm a friend of person A > > > and person A is a friend of Person B' > > > But I really don't like person B' and I have rejected his friend > > > request.
> > > Are we not exposing my information to Person B' (indirectly through > > > Person A)
> > > I think there is a privacy issue here, unless all the data information > > > is set to public.
> > > On Apr 3, 9:52 am, Cassie <d...@google.com> wrote: > > > > The opensocial people fetching is sorta limited right now. You can't > > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also > can't > > > > ask for the VIEWER's friends of friends or reference any other > > > > grouping mechanism. I propose that we address all of this somehow by > > > > changing either the idSpec type, the newFetchPeopleRequest call or > > > > some combination of the two.
> > > > Here is what we have right now:
> > > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends > -- > > > > not a real js object > > > > - newFetchPeopleRequest takes in an idSpec to tell it which people > to > > > fetch. > > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" > and > > > > another idSpec that a person has to be friends with
> > > > Here is something we could do instead:
> > > > idSpec becomes a real object "opensocial.idSpec" with three fields: > > > > - userId > > > > - groupid > > > > - networkDistance (? - see below)
> > > > This would change the old idSpecs as follows:
> > > > Containers could support additional groupIds, allowing opensocial to > > > > slowly add support for that type of functionality as well. We could > > > > also use a "networkDistance" field to idSpec which would then allow > > > > you to do friends of friends:
> > > > I'm not sure if the networkDistance makes sense for non FRIENDS > groups > > > though. > > > > (but we do get to move it out of the isFriendsWith filterOptions if > we > > > > put it in the idSpec object as well)
> > > > The isFriendsWith filter still makes sense with this new object but > it > > > > has more power. You can ask for the friends that bob and suzie both > > > > share:
> > > > Some of these requests could get extremely complicated, but each > > > > container will always be able to choose to support only what it > wants > > > > to support. A container also always has the right to deny access to > > > > someone's data, group membership or anything else. I think this > simply > > > > will make opensocial more flexible for those containers who really > > > > like network connections and support friends of friends and other > such > > > > things.
> > > > Alright, so after all that, what do you think? > > > > And please chime in if you have a simpler yet just as flexible idea! > > > > Thanks.
Okay, so given that everything is optional as usual (don't worry you won't have to fetch all of my friends 8 times removed :) and that we have paging it seems like:
reinoud, marco, eiji, louis, cassie (and maybe even evan) all agree Unless there are any objections this is going in for 0.8
On Tue, Apr 22, 2008 at 7:02 PM, Reinoud Elhorst <rein...@hyves.nl> wrote: > On Tue, Apr 22, 2008 at 6:50 PM, Marco <ens...@gmail.com> wrote:
>> Ok I can see the benefits as well. Let's make the NETWORK_DISTANCE >> feature optional for the container.
> It's up to the container whether they want to support any NETWORK_DISTANCE > above N. In the case than N=1, the container does not support 2nd degree > networks at all, effectively making support for the NETWORK_DISTANCE > parameter optional.
>> On Apr 22, 2:49 am, "Reinoud Elhorst" <rein...@hyves.nl> wrote: >> > These policies are obviously up to the container, but I would imagine >> that >> > no container should expose data in this case that the viewer does not >> have >> > access to through some other channel. The same obviously is true for >> owner: >> > the viewer should never be able to get more information from the owner >> than >> > the privacy settings allow. Whether the same is true the other way round >> is >> > a more difficult question: >> > Is the applications, that might be acting on behalf of the owner, >> allowed to >> > get more information from the viewer than the owner himself could? >> However, >> > this again is a question the containers need to solve for themselves.
>> > On Mon, Apr 21, 2008 at 7:45 PM, Marco <ens...@gmail.com> wrote:
>> > > Is there not a more fundamental problem that the 2nd degree friends >> > > never has given permission to share all the data to the outside world? >> > > I can imagine I'm a friend of person A >> > > and person A is a friend of Person B' >> > > But I really don't like person B' and I have rejected his friend >> > > request.
>> > > Are we not exposing my information to Person B' (indirectly through >> > > Person A)
>> > > I think there is a privacy issue here, unless all the data information >> > > is set to public.
>> > > On Apr 3, 9:52 am, Cassie <d...@google.com> wrote: >> > > > The opensocial people fetching is sorta limited right now. You can't >> > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also >> can't >> > > > ask for the VIEWER's friends of friends or reference any other >> > > > grouping mechanism. I propose that we address all of this somehow by >> > > > changing either the idSpec type, the newFetchPeopleRequest call or >> > > > some combination of the two.
>> > > > Here is what we have right now:
>> > > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends >> -- >> > > > not a real js object >> > > > - newFetchPeopleRequest takes in an idSpec to tell it which people >> to >> > > fetch. >> > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith" >> and >> > > > another idSpec that a person has to be friends with
>> > > > Here is something we could do instead:
>> > > > idSpec becomes a real object "opensocial.idSpec" with three fields: >> > > > - userId >> > > > - groupid >> > > > - networkDistance (? - see below)
>> > > > This would change the old idSpecs as follows:
>> > > > Containers could support additional groupIds, allowing opensocial to >> > > > slowly add support for that type of functionality as well. We could >> > > > also use a "networkDistance" field to idSpec which would then allow >> > > > you to do friends of friends:
>> > > > I'm not sure if the networkDistance makes sense for non FRIENDS >> groups >> > > though. >> > > > (but we do get to move it out of the isFriendsWith filterOptions if >> we >> > > > put it in the idSpec object as well)
>> > > > The isFriendsWith filter still makes sense with this new object but >> it >> > > > has more power. You can ask for the friends that bob and suzie both >> > > > share:
>> > > > Some of these requests could get extremely complicated, but each >> > > > container will always be able to choose to support only what it >> wants >> > > > to support. A container also always has the right to deny access to >> > > > someone's data, group membership or anything else. I think this >> simply >> > > > will make opensocial more flexible for those containers who really >> > > > like network connections and support friends of friends and other >> such >> > > > things.
>> > > > Alright, so after all that, what do you think? >> > > > And please chime in if you have a simpler yet just as flexible idea! >> > > > Thanks.
i can see FoF determination for thinks like "mutual matching" for
dating, or "business networking" apps. you are more likely to have a
way of being introduced to someone if you have some relationship that
could bridge the gap. i think 3rd degree might be a bit extreme.
i can't see wanting the list, but I can see wanting to know if the
viewer is a FoF of the owner, or vice versa.
viewer.isFoF(person:ID) would be nice.
On Apr 24, 10:32 am, Cassie <d...@google.com> wrote:
> Okay, so given that everything is optional as usual (don't worry you won't
> have to fetch all of my friends 8 times removed :) and that we have paging
> it seems like:
> reinoud, marco, eiji, louis, cassie (and maybe even evan) all agree
> Unless there are any objections this is going in for 0.8
> Thanks.
> - Cassie
> On Tue, Apr 22, 2008 at 7:02 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> > On Tue, Apr 22, 2008 at 6:50 PM, Marco <ens...@gmail.com> wrote:
> >> Ok I can see the benefits as well. Let's make the NETWORK_DISTANCE
> >> feature optional for the container.
> > It's up to the container whether they want to support any NETWORK_DISTANCE
> > above N. In the case than N=1, the container does not support 2nd degree
> > networks at all, effectively making support for the NETWORK_DISTANCE
> > parameter optional.
> >> On Apr 22, 2:49 am, "Reinoud Elhorst" <rein...@hyves.nl> wrote:
> >> > These policies are obviously up to the container, but I would imagine
> >> that
> >> > no container should expose data in this case that the viewer does not
> >> have
> >> > access to through some other channel. The same obviously is true for
> >> owner:
> >> > the viewer should never be able to get more information from the owner
> >> than
> >> > the privacy settings allow. Whether the same is true the other way round
> >> is
> >> > a more difficult question:
> >> > Is the applications, that might be acting on behalf of the owner,
> >> allowed to
> >> > get more information from the viewer than the owner himself could?
> >> However,
> >> > this again is a question the containers need to solve for themselves.
> >> > On Mon, Apr 21, 2008 at 7:45 PM, Marco <ens...@gmail.com> wrote:
> >> > > Is there not a more fundamental problem that the 2nd degree friends
> >> > > never has given permission to share all the data to the outside world?
> >> > > I can imagine I'm a friend of person A
> >> > > and person A is a friend of Person B'
> >> > > But I really don't like person B' and I have rejected his friend
> >> > > request.
> >> > > Are we not exposing my information to Person B' (indirectly through
> >> > > Person A)
> >> > > I think there is a privacy issue here, unless all the data information
> >> > > is set to public.
> >> > > On Apr 3, 9:52 am, Cassie <d...@google.com> wrote:
> >> > > > The opensocial people fetching is sorta limited right now. You can't
> >> > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also
> >> can't
> >> > > > ask for the VIEWER's friends of friends or reference any other
> >> > > > grouping mechanism. I propose that we address all of this somehow by
> >> > > > changing either the idSpec type, the newFetchPeopleRequest call or
> >> > > > some combination of the two.
> >> > > > Here is what we have right now:
> >> > > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends
> >> --
> >> > > > not a real js object
> >> > > > - newFetchPeopleRequest takes in an idSpec to tell it which people
> >> to
> >> > > fetch.
> >> > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith"
> >> and
> >> > > > another idSpec that a person has to be friends with
> >> > > > Here is something we could do instead:
> >> > > > idSpec becomes a real object "opensocial.idSpec" with three fields:
> >> > > > - userId
> >> > > > - groupid
> >> > > > - networkDistance (? - see below)
> >> > > > This would change the old idSpecs as follows:
> >> > > > Containers could support additional groupIds, allowing opensocial to
> >> > > > slowly add support for that type of functionality as well. We could
> >> > > > also use a "networkDistance" field to idSpec which would then allow
> >> > > > you to do friends of friends:
> >> > > > I'm not sure if the networkDistance makes sense for non FRIENDS
> >> groups
> >> > > though.
> >> > > > (but we do get to move it out of the isFriendsWith filterOptions if
> >> we
> >> > > > put it in the idSpec object as well)
> >> > > > The isFriendsWith filter still makes sense with this new object but
> >> it
> >> > > > has more power. You can ask for the friends that bob and suzie both
> >> > > > share:
> >> > > > Some of these requests could get extremely complicated, but each
> >> > > > container will always be able to choose to support only what it
> >> wants
> >> > > > to support. A container also always has the right to deny access to
> >> > > > someone's data, group membership or anything else. I think this
> >> simply
> >> > > > will make opensocial more flexible for those containers who really
> >> > > > like network connections and support friends of friends and other
> >> such
> >> > > > things.
> >> > > > Alright, so after all that, what do you think?
> >> > > > And please chime in if you have a simpler yet just as flexible idea!
> >> > > > Thanks.
> i can see FoF determination for thinks like "mutual matching" for
> dating, or "business networking" apps. you are more likely to have a
> way of being introduced to someone if you have some relationship that
> could bridge the gap. i think 3rd degree might be a bit extreme.
> i can't see wanting the list, but I can see wanting to know if the
> viewer is a FoF of the owner, or vice versa.
> viewer.isFoF(person:ID) would be nice.
> On Apr 24, 10:32 am, Cassie <d...@google.com> wrote:
> > Okay, so given that everything is optional as usual (don't worry you won't
> > have to fetch all of my friends 8 times removed :) and that we have paging
> > it seems like:
> > reinoud, marco, eiji, louis, cassie (and maybe even evan) all agree
> > Unless there are any objections this is going in for 0.8
> > Thanks.
> > - Cassie
> > On Tue, Apr 22, 2008 at 7:02 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> > > On Tue, Apr 22, 2008 at 6:50 PM, Marco <ens...@gmail.com> wrote:
> > >> Ok I can see the benefits as well. Let's make the NETWORK_DISTANCE
> > >> feature optional for the container.
> > > It's up to the container whether they want to support any NETWORK_DISTANCE
> > > above N. In the case than N=1, the container does not support 2nd degree
> > > networks at all, effectively making support for the NETWORK_DISTANCE
> > > parameter optional.
> > >> On Apr 22, 2:49 am, "Reinoud Elhorst" <rein...@hyves.nl> wrote:
> > >> > These policies are obviously up to the container, but I would imagine
> > >> that
> > >> > no container should expose data in this case that the viewer does not
> > >> have
> > >> > access to through some other channel. The same obviously is true for
> > >> owner:
> > >> > the viewer should never be able to get more information from the owner
> > >> than
> > >> > the privacy settings allow. Whether the same is true the other way round
> > >> is
> > >> > a more difficult question:
> > >> > Is the applications, that might be acting on behalf of the owner,
> > >> allowed to
> > >> > get more information from the viewer than the owner himself could?
> > >> However,
> > >> > this again is a question the containers need to solve for themselves.
> > >> > On Mon, Apr 21, 2008 at 7:45 PM, Marco <ens...@gmail.com> wrote:
> > >> > > Is there not a more fundamental problem that the 2nd degree friends
> > >> > > never has given permission to share all the data to the outside world?
> > >> > > I can imagine I'm a friend of person A
> > >> > > and person A is a friend of Person B'
> > >> > > But I really don't like person B' and I have rejected his friend
> > >> > > request.
> > >> > > Are we not exposing my information to Person B' (indirectly through
> > >> > > Person A)
> > >> > > I think there is a privacy issue here, unless all the data information
> > >> > > is set to public.
> > >> > > On Apr 3, 9:52 am, Cassie <d...@google.com> wrote:
> > >> > > > The opensocial people fetching is sorta limited right now. You can't
> > >> > > > fetch Bob's friends, only the VIEWER and OWNER friends. You also
> > >> can't
> > >> > > > ask for the VIEWER's friends of friends or reference any other
> > >> > > > grouping mechanism. I propose that we address all of this somehow by
> > >> > > > changing either the idSpec type, the newFetchPeopleRequest call or
> > >> > > > some combination of the two.
> > >> > > > Here is what we have right now:
> > >> > > > - idSpec = array of ids, viewer, owner, viewerfriends, ownerfriends
> > >> --
> > >> > > > not a real js object
> > >> > > > - newFetchPeopleRequest takes in an idSpec to tell it which people
> > >> to
> > >> > > fetch.
> > >> > > > - another wip proposal of 0.8 is to add the filter "isFriendsWith"
> > >> and
> > >> > > > another idSpec that a person has to be friends with
> > >> > > > Here is something we could do instead:
> > >> > > > idSpec becomes a real object "opensocial.idSpec" with three fields:
> > >> > > > - userId
> > >> > > > - groupid
> > >> > > > - networkDistance (? - see below)
> > >> > > > This would change the old idSpecs as follows:
> > >> > > > Containers could support additional groupIds, allowing opensocial to
> > >> > > > slowly add support for that type of functionality as well. We could
> > >> > > > also use a "networkDistance" field to idSpec which would then allow
> > >> > > > you to do friends of friends:
> > >> > > > I'm not sure if the networkDistance makes sense for non FRIENDS
> > >> groups
> > >> > > though.
> > >> > > > (but we do get to move it out of the isFriendsWith filterOptions if
> > >> we
> > >> > > > put it in the idSpec object as well)
> > >> > > > The isFriendsWith filter still makes sense with this new object but
> > >> it
> > >> > > > has more power. You can ask for the friends that bob and suzie both
> > >> > > > share:
> > >> > > > Some of these requests could get extremely complicated, but each
> > >> > > > container will always be able to choose to support only what it
> > >> wants
> > >> > > > to support. A container also always has the right to deny access to
> > >> > > > someone's data, group membership or anything else. I think this
> > >> simply
> > >> > > > will make opensocial more flexible for those containers who really
> > >> > > > like network connections and support friends of friends and other
> > >> such
> > >> > > > things.
> > >> > > > Alright, so after all that, what do you think?
> > >> > > > And please chime in if you have a simpler yet just as flexible idea!
> > >> > > > Thanks.
|
