Supporting more general people fetching

[Cassie]

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:

"VIEWER" = {userId : VIEWER}
"VIEWER_FRIENDS" = {userId : VIEWER, groupId : FRIENDS}
123 = {userId : 123}
123's friends(not possible before) = {userId : 123, groupId: FRIENDS}

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:

"VIEWER's friends of friends" = {userId : VIEWER, groupId : FRIENDS,
networkDistance: 1}

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:

idSpec = {userId: bob, groupId : FRIENDS} filterType = isFriendsWith
filterOptions = {idSpec: {userId: Suzie, groupId: FRIENDS} }

or maybe even all of suzie's friends that are friends with people on
the soccer team

idSpec = {userId: suzie, groupId : FRIENDS} filterType =
isFriendsWith filterOptions = {idSpec: {groupId: SOCCER_TEAM} }

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

[Evan Gilbert]

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

[Louis Ryan]

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?

VIEWER's friends of friends" = {userId : VIEWER, groupId : FRIENDS,
networkDistance: 1}

-Louis

[Cassie]

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

[Eiji Kitamura]

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 <do...@google.com>:

[Reinoud Elhorst]

-----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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH9jG+qCQnCrE98GgRAvltAKCXuHA4Rpjjc80JGwOcoKHXc7nrSQCeJpgM
HmbxELnIOxtkopndsgljb+I=
=I0Bn
-----END PGP SIGNATURE-----

[Cassie]

Eiji - There is a filtering by friends proposal already on the table here:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/95570a27ab945f6d#
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?

Spec change for this would be:

1. Add a new opensocial.IdSpec object.
opensocial.IdSpec = function() {};
opensocial.IdSpec.Field = {
USER_ID : 'userId',
GROUP_ID : 'groupId',
NETWORK_DISTANCE : 'networkDistance',
}
opensocial.IdSpec.prototype.getField = function(key) {};

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

[Marco]

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.

[Reinoud Elhorst]

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.

[Eiji Kitamura]

Cassie,

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?
>
> Spec change for this would be:
>
> 1. Add a new opensocial.IdSpec object.
> opensocial.IdSpec = function() {};
> opensocial.IdSpec.Field = {
>   USER_ID : 'userId',
>   GROUP_ID : 'groupId',
>   NETWORK_DISTANCE : 'networkDistance',}
>
> opensocial.IdSpec.prototype.getField = function(key) {};
>
> 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
>

> >> 2008/4/4, Cassie <d...@google.com>:

> > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org

[Marco]

Ok I can see the benefits as well. Let's make the NETWORK_DISTANCE
feature optional for the container.

> > > - Cassie- Hide quoted text -
>
> - Show quoted text -

[Reinoud Elhorst]

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.

[Cassie]

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

[jdavid.net]

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
>

[jdavid.net]

for that matter it would be nice to limit the link to Friend of
Friend, Relitive of Friend, and or some other relationship description
of a friend.