($and/ <== DO NOT REMOVE - switch for preventing MathML interpretation of dollar signs on this page)

About

This page discusses the basic XDI graph structures, patterns, and flows for group messaging, i.e. XDI messaging that involves more than 2 peers. This can be used for group profile sharing, group chat messages, group email "lists", group connection requests, and any other kind of data or operation that can be expressed in XDI.

Change Log

Group Nodes

Addressing

In XDI, a group is a first-class graph node just like a person or a thing. As defined in section 4.2.2. of XDI Core 1.0 CSD 01, a group is a + node. Like any other XDI entity, the XDI address of a group node can be absolute or relative, and it can be mutable or immutable.

+!:uuid:x-1                 <== absolute, immutable
+example-group              <== absolute, mutable
=!:uuid:x-2+!~1234          <== relative, immutable
=!:uuid:x-2+~local-group    <== relative, mutable

Note that while a group node with absolute XDI address may appear at any level of context, a group node with a relative XDI address MUST be relative to another entity node.

Specialization

Group nodes can also be specialized. For example:

=!:uuid:x-2+!:uuid:x-1          <== absolute group +!:uuid:x-1 specialized by an absolute person =!:uuid:x-2
+!:uuid:x-3+!:uuid:x-1          <== absolute group +!:uuid:x-1 specialized by another absolute group +!:uuid:x-3

The purpose of this specialization is to create instances of the same semantic entity -- in this case the group +!:uuid:x-1 -- in different semantic contexts so descriptions of this group can be specialized for those contexts. For example:

=!:uuid:x-2+!:uuid:x-1<#notes>     <== notes that person =!:uuid:x-2 is keeping about group +!:uuid:x-1
+!:uuid:x-3+!:uuid:x-1<#notes>     <== notes that group =!:uuid:x-3 is keeping about group +!:uuid:x-1

Membership

Membership in a group is defined in section 10.4 of XDI Core 1.0 CSD 01. It MUST use $has relations. Example:

+!:uuid:x-1/$has/=!:uuid:x-2
+!:uuid:x-1/$has/=!:uuid:x-3
+!:uuid:x-1/$has/=!:uuid:x-4

Group membership can also be discovered from inverse group membership statements, e.g.:

=!:uuid:x-2/$is$has/+!:uuid:x-1
=!:uuid:x-3/$is$has/+!:uuid:x-1
=!:uuid:x-4/$is$has/+!:uuid:x-1

Messages

Messages are represented by entity instances in a [$msg] entity collection.

In the most simple case, messages may be directly in the context of the group itself:

+!:uuid:x-1[$msg]

Messages however may also be further qualified to model concepts such as channels, queues, conversations, etc:

+!:uuid:x-1[$queue]*!:uuid:ex-7[$msg]

Generation of a new group node is identical to generation of a new person node except that the bootstrap link contract is for permissions on the group node. For example, here are the "genesis statements" for adding a new person node =!:uuid:x-2 and its root link contract:

//=!:uuid:x-2
(=!:uuid:x-2/=!:uuid:x-2)$do/$all/

Here are the genesis statements for a new group node +!:uuid:x-1 and a bootstrap link contract that gives all permissions over this group node to the individual =!:uuid:x-2.

//+!:uuid:x-1
(+!:uuid:x-1/=!:uuid:x-2)$do/$all/+!:uuid:x-1

Messages can be sent to the group using the publisher link contract.

The link contract grants $add permission on the [$msg] entity collection of the group.

The group takes the role of both publishing peer and subscribing peer:

The link contract's policy requires the publishers to be members of the group:

(+!:uuid:x-1/+!:uuid:x-1)$do/$add/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)($do$if$and/$true)+!:uuid:x-1/$has/{$from}
(+!:uuid:x-1/+!:uuid:x-1)($do$if$and/$true){$msg}<$sig><$valid>/&/true

Messages are distributed by the subscriber link contract.

This is a push link contract which covers the [$msg] entity collection of the group.

The group takes the role of both publishing peer and subscribing peer:

The link contract's policy requires the subscribers to be members of the group:

(+!:uuid:x-1/+!:uuid:x-1)$push$do/$push/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true)+!:uuid:x-1/$has/{$to}
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true){$msg}<$sig><$valid>/&/true

The basic admin responsibilities of adding and deleting members can be accomplished by the individuals who have admin permissions as shown in the following group administration link contract:

(+!:uuid:x-1/=!:uuid:x-2)($do/$add)+!:uuid:x-1/$has/{}
(+!:uuid:x-1/=!:uuid:x-2)($do/$del)+!:uuid:x-1/$has/{}

Basic Group Messaging

Messages are sent using a $add operation to add a message to the [$msg] entity collection:

=!:uuid:x-2/$send/=!:uuid:x-2[$msg]*!:uuid:x-8
=!:uuid:x-2[$msg]*!:uuid:x-8/$is()/(+!:uuid:x-1)
=!:uuid:x-2[$msg]*!:uuid:x-8/$do/(+!:uuid:x-1/+!:uuid:x-1)$do
=!:uuid:x-2[$msg]*!:uuid:x-8$do/$add/{$msg}
=!:uuid:x-2[$msg]*!:uuid:x-8<$string>/&/"hello world"

Group Membership Invitations and Requests

This section will describe how new peers can request membership, how they can be invited for membership, and how members can leave a group.

Encrypted Group Messaging

This section will build on the previous section by describing options for message signing and encryption to achieve integrity, authenticity and confidentiality.

Articles on multi-party encrypted messaging:

Notes

  1. A group can take actions, e.g., generate and sign messages, the same way a person or a thing can.
  2. Persons (=entities) acting on behalf of a group (+entity) of which they are members is similar to agents (*entities) acting on behalf of a person (=entity).
  3. Group messaging has two basic topographies:
    1. Hub-style: any member of the group who sends a message to the group writes it to the hub, and the hub redistributes the messages to rest of the members as spokes.
    2. P2P-style: any member of the group writes a message to the group and if the message is from that member, the peer sends it to all the other peers. So each peer is responsible for sending messages from its group member.
  4. The difference between hub-and-spoke and P2P group messaging link contracts needs to be in the link contract semantics.

OPEN ISSUES

  1. Should link contract permissions be assignable directly to a group?
  2. If so, should we define that all members of the group have those permissions? Note that if a subgroup of members (e.g. admins) are the only ones who should have those permissions, they can be defined as a group within the group.

GroupMessaging (last edited 2016-03-22 13:09:55 by peacekeeper)