XDI
TC Notes
Following are the notes of the unofficial
telecon of the XDI TC held on:
Date: Monday, 4 January 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
Drummond Reed
Les Chasen
Markus Sabadello
Joseph Boyle
REGRETS
Update on Publishing XDI Core 1.0 Committee
Specification Draft 01
Drummond gave a brief report on progress.
https://lists.oasis-open.org/archives/xdi/201511/msg00011.html
Chet and Ken Holman from the OASIS DocBook TC
got back to Joseph and Drummond with answers to most of our
questions. That leaves two final tasks:
# ACTION ITEM: JOSEPH AND DRUMMOND to do a
final joint editing session.
# ACTION ITEM: DRUMMOND to add a wiki page
with any proposed revisions for future versions of XDI Core
1.0.
XDI Agent Demo
Markus gave another demo of new functionality
he has developed for an XDI agent (a Java desktop app) that
can connect to XDI endpoints:
https://github.com/projectdanube/XDINinja-swing
In this demo, he showed an “automatic”
connection invitation. In this scenario, Alice sends a
connection invitation to Bob, and when Bob accepts, the
connection request from Bob back to Alice is automatically
accepted by Alice.
To do this, the link contract policy
specifies that it will accept an XDI message with a specific
digest hash value. This uses the $digest keyword, which
Markus will add to the Messaging spec.
The other new functionality is an XDI chat
functionality. Markus has implemented this with two link
contracts, one in both directions, between Alice and Bob.
These link contracts are in fact quite similar to the ones
for reading and writing profile data that Markus showed last
week.
He showed basic chat messaging between Alice
and Bob. These messages are not encrypted but they both have
signatures—one from the sender (applied by the agent) to
verify the message at Alice’s endpoint, and then one applied
by Alice’s endpoint to send to Bob’s endpoint.
Markus explained that the addition of
signatures and encryption, and the removal of signatures and
encryption, are all controlled either by parameters on a
message or server configuration. However the basic sequence
of operations is the same, and this is what is documented in
Markus’ earlier flow diagrams and in the Messaging spec.
Markus felt that some sequence diagrams will be needed in
the Messaging spec.
Queues, Conversations, Channels, and Group
Messaging
Drummond brought up the idea of messaging
queues and conversations as a design approach that enables a
single link contract to control access to the queue. This
took us into a whole set of topics around design patterns
for direct and group messaging.
Markus took the following group notes about
this conversation:
A queue has a UUID [$queue]*!:uuid:ex-1
A queue contains a set of conversations
Conversations have UUIDs
[$conversation]*!:uuid:ex-2
and [$conversation]*!:uuid:ex-3
# ACTION ITEM: ALL think about $ dictionary
word for conversations that is shorter than “$conversation”.
A conversation is a sequence of messages.
Alice and bob want link contract to share a
queue that allows both to read/write messages and
conversations.
Current "bi-directional link contract
pattern" used in XDI Ninja demo app for chat:
(=alice/=bob)$do/$set/=alice#chat$channel[$msg]
(=alice/=bob)$do$if/...
(=bob/=alice)$do/$set/=bob#chat$channel[$msg]
(=bob/=alice)$do$if/...
Closed "centrally controlled" channel:
(=alice/+group)$do/$set/=alice#chat$channel[$msg]
(=alice/+group)($do$if/$true)+group/$has/{$from}
+group/$has/=bob
+group/$has/=charlie
-> =alice controls list of group members
-> all message are sent via =alice
(centralized, hub-and-spoke channel)
-> group/channel lifecycle is controlled
by =alice
Proposed shared queue context link contract
pattern:
(=alice)+group/$has/=alice
(=alice)+group/$has/=bob
(=alice)+group/$has/=charlie
(=bob)+group/$has/=alice
(=bob)+group/$has/=bob
(=bob)+group/$has/=charlie
(=charlie)+group/$has/=alice
(=charlie)+group/$has/=bob
(=charlie)+group/$has/=charlie
-> group continues to exist as long as
it still has at least 1 member
-> new members joining requires / does
not require invitation from existing member (depends on
policy)
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