OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XDI TC Notes Unofficial Telecon Monday 2016-03-14


XDI TC Notes


Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Monday, 14 March 2016 USA
Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30 UTC)


The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Markus Sabadello
Phil Windley
Les Chasen
Joseph Boyle
Kapil Vats
Drummond Reed


Multi-Party (Group) Messaging

Per their action item from the last call, Markus and Drummond posted a new wiki page that documents last week’s discussion and proposes a roadmap to complete our definition of group messaging.


https://wiki.oasis-open.org/xdi/GroupMessaging


Note that secure messaging group messaging is actually the final step in this roadmap; we have several steps to complete first. We will use this page to prioritize, discuss, and document our progress.


We started by discussion group messaging versus 1-to-1 or direct messaging. We agreed that group messaging always involves a group, however, a series of direct messages may also have a user experience similar to a group. An example Markus gave was multiple subscribers to an XDI business card change-of-address.


Drummond noted that XDI Core 1.0 CSD 01 section 4.2.2, where we define group entities, does not currently mention the possibility of groups being members of groups—and it should. This is a common pattern in directory services. He has already added this change to the XDI Core 1.0 revisions wiki page.


Drummond also noted that group management is different than personal node management in that a group may have multiple authoritative endpoints that need to be maintained/synchronized in a P2P fashion. Markus was not sure that it makes sense for a group to have multiple authoritative endpoints. He described a scenario where a group has no independent authority, but only exists in the graph of individuals who are members or administrators of the group. He also pointed out that individuals acting on behalf of a group can be thought of as directly analogous to agents acting on behalf of an individual.


Drummond noted that again we are seeing the parallels between a group graph and a person graph.


Les asked about the need to form ad hoc groups—lightweight groups that are formed for a short-term purpose, such as a conversation, and then disbanded when that conversation is finished. Even then, the group would have its own group node with its own XDI address.


Drummond noted that even two-person messaging conversations can benefit from being modeled as a group with its own group ID because then only one shared link contract is needed.


We summarized the conversation by saying there are three options for group endpoints:

  1. No discoverable endpoint. The group exists only in the graphs of the members using it—e.g., an ad hoc discussion group.

  2. Single discoverable endpoint. In this case, there is one endpoint acting as authoritative for the group—e.g., a corporate workgroup. This can easily use a hub-and-spoke synchronization pattern.

  3. Multiple discoverable endpoints. In this case, the group is administered by multiple authorities in a many-to-many scenario—e.g., a golf group where all the golfers are maintaining the group. An extreme example of this is the shared state of a distributed ledger on a blockchain.


Markus had concerns about how the third option would work. For example, how would someone discover the authoritative public key for the group in order to send a confidential message? Drummond agreed that the complexity increased but ultimately the “chain of authority” could still be expressed clearly even in a P2P scenario.


Les also shared the concern about the complexity of #3. Drummond acknowledged that complexity, but said that it doesn’t mean we should not allow it.


We concluded that this had been a good discussion of the basic group constructs and agreed that the next topic should be the basic group messaging link contracts, followed by group membership invitations and requests.


# ACTION ITEM: Markus and Drummond to create the next set of proposal on group messaging to review on next week’s call.


# ACTION ITEM: Drummond to add an example to the wiki page of an absolute group node under another absolute node.


NEXT REGULAR CALL

The next call will be the following week at the usual time (Monday 10AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]