about Group Service in Social API

[Laurent-Walter Goix]

Hi all,
I am starting to dig into the Group Service and am having some trouble understanding how certain features are achieved from the spec.i hope you can advise me.

After a first rough check, I couldn't find clearly how to join/leave a group using that service. Is there any specific use of the post/delete or am i supposed to do so by posting an activity entry with the appropriate verb? In any case it would be helpful to document the best practise.

Then,as groups are intended as both multi-user (regular interest groups) and private (user-defined lists), where should this information about privacy-level etc be included when creating a group? Group information / data model is very poor currently..

I may have further doubts as i go down checking the specs but clarifying these two first aspects would help a lot!
Thanks
Walter

[Laurent-Walter Goix]

After a deeper check i noticed that the action of joining/leaving groups could be understood as creating/deleting relationships under the People Service. If this is the main way of achieving this, it may deserve some clarifying text in the spec to state so. let me know if you want me to submit a issue/patch for it.

regarding privacy constraints when creating the group, i still couldn't find any way of adding this information. any hint?

[Matthew Marum]

So, as I recall, the Group service was originally for a user to organize their list of friends by putting them into groups (I think a better name would be 'Category service').  I'm not sure how widely adopted that service is.  It is in the spec for historical reasons.  It wasn't really designed for implementing security/privacy constraints.

For the most part, visibility is something that has been left up to individual applications.

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensocial-and-gadg...@googlegroups.com.
To post to this group, send email to opensocial-an...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/opensocial-and-gadgets-spec/d2eb01df-cb16-4786-912b-f3134eea9207%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Niels van Dijk]

Hi,

On 10/17/2013 03:57 PM, Matthew Marum wrote:
> So, as I recall, the Group service was originally for a user to organize
> their list of friends by putting them into groups (I think a better name
> would be 'Category service'). I'm not sure how widely adopted that
> service is. It is in the spec for historical reasons. It wasn't really
> designed for implementing security/privacy constraints.
>

We are currenlty running a nation wide collborative service (SURFconext,
http://www.surfnet.nl/en/Thema/coin/Pages/default.aspx) which supports
using OpenSocial Group and Person API calls as one of the means of
getting this data and exchanging it between the platform and remote
applications. In addition it is part of the OpenSource OpenConext
platform used to run SURFconext (github.com/openconext).

We do not use the API to create or leave groups, that is handled via a
seperate application.

We do implement private groups, and only present these to a user that is
a member of the specific group. Having a property of a group stating it
is private seems a bit redundant, as that would already leak the
existense of the group to be able to get the property?
We only release attributs of people and groups in accordance with our
policies and after consent from users.

In regard to Security and Privacy I think the OpenSocial Spec simply
states that it is up to the container to decide what kind of data to
provide on users and groups. In The Netherlands, several of the person
data in the spec are considered privacy sesitive. This also is true for
the fact that somebody is a member of a group.

Cheers,
Niels

[Laurent-Walter Goix]

hi all,

thanks for your answers. indeed i'd like to refresh that service to make it work out for multi-user groups as well. there are requirements in OMA to do so so we may address them here in opensocial or within the OMA spec. i wonder if others are interested as well but the existing api is pretty ready i think.

re the group data model, i believe it can greatly be enhanced..one possibility could be to migrate it to the AS group object, which is a plain object wrt AS (no additional property) but at least inherits as such some additional properties (as a matter of fact "id" already exist, whilst "title" maps to "displayName" and "description" to "content"). another option is simply to extend the current data model. a third option is to refer to an existing/popular data model for groups (any hint?)

re privacy this could be handled via the api (by posting to something else than a User-Id, e.g. "@all" or with no User-Id to create a public group), but still some flexibility would be missing to indicate all the group's acl so i am starting to think more about adding this to the group data model itself...
opinions?

thanks
walter