Overview

Group module is responsible for management of peers group. Groups are created from collecting personal identities provided by Personal Identifier module. In order for a user to use contacts of friends from a give network, he must first sign-in using user’s account credentials. Once user is signed in, he can choose among available contacts and select the peers with whom he would like to share the content. A peer group can be defined individually per widget.  A group may also be saved and be reused for other widgets. 

Peers-group is a list of contacts for sharing content with. Peers-groups is assigned with each Widget either explicitly or by user interface.  Contacts in a peers-group are able to view and possibly edit the shared Widget, assuming they are signed-in with their personal identifier set in the group. Peers-group may be defined programmatically, by application or manually by user.

Here is an example, assuming a TextBox widget with group that contains:

  1. tiram.gilad@gmail.com
  2. rhizome.networks@gmail.com
  3. facebook.com/gilad.tiram 

There are three contacts in this group. A user who is signed-in with either of these contacts (possibly more than one) will be able to view the shared Widget.

As mentioned earlier peers-groups are capable of being managed programmatically and the group of peers that share the widget may not always be exposed to the user. There are situations in which a group is managed programmatically and users share data, without being aware of the full scope of the actual peers-group. For example, assume an app that would like to provide multi lingual translation of messages to passengers in the same train. This app works with Ad hoc group in order to provide dynamic group of passengers with whom translation needs to be shared. In this situation the group is not fixed, and peers in the group have no scope (at least not in the simple case) of the other peers in the group. Instead users are added and removed from the group dynamically once they scan the train code.

Content Relevancy

It is known especially with related to social-networks that some people tend to create huge list of friends which are not thoroughly part of their close circle. For example one can have 500 connections on LinkedIn but personally one is familiar with only 20 of them. Since CG by its nature present shared content on top of other contexts, is intend for sharing with close circle of peers that are willing to be exposed with the data. Relevancy is the key temm or else a technology like CG can easily turn into unbearable advertising and marketing tool that miss its initial purpose.  

CG system provide a combination of several solutions that will be combined for the purpose of focusing on relancy: 

  1. Setting Contacts scope: this is an advanced setting that allows user to choose for supported PIDN scope from where contact will be loaded. For example setting a specific Contacts group in Google to limit the list of contact to those in the group. Contact scope be unidirectional meaning that difference scope may be defined for sharing operation and viewing of shared content, or bidirectional meaning that the same scope is applied to shared content and viewing of shared content as well.
  2. Setting Include Exclude lists: This is an advance setting that let user set a list of contacts to be included from given PIDN. Only those contacts in the include list will be available for setting as peers in the peers group settings. On the same manner user will be able to set  a list of excluded contacts, in order to prevent from certain contacts to be available for setting in peers group. Exclude and Include lists are may be unidirectional meaning that different lists may be set for sharing operation and shared content  or  bidirectional meaning that the same list can be applied to shared content and sharing operation as well.
  3. Acceptance:  Viwing modes that let user accept sharing before it benig expose to widgets and other restrictions that can be set in order to maximise relevancy ofexposure to information.