From 9b767e70e16e879a81b9ddbedd47e4fc21155bdd Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Fri, 18 Dec 2015 15:33:11 +0000 Subject: [PATCH] Slightly update after offlist discussion This removes the participant ID, as we want to use JIDs for this. It also puts TODOs around discussions for use of 'real' pubsub for messages and presence from the room and makes presence to the room explicitly a normal presence stanza --- inbox/mix.xml | 66 ++++++++++++++++++++++----------------------------- 1 file changed, 29 insertions(+), 37 deletions(-) diff --git a/inbox/mix.xml b/inbox/mix.xml index c4bf75a8..9302ad7e 100644 --- a/inbox/mix.xml +++ b/inbox/mix.xml @@ -75,17 +75,17 @@
  • MIX conversations (roughly equivalent to MUC rooms) are hosted on a MIX domain, e.g. `mix.example.com`, which is discoverable through &xep0030;. Each conversation on the service may then be discovered and queried.
  • Re-using the model from &xep0163; (where every user JID (e.g., `user@example.com`) is its own pubsub service), in MIX each conversation (e.g., `conversation@mix.example.com`) is a pubsub service.
  • A conversation's pubsub service can contains any number of nodes for different event types or data formats. As described below, this document defines several standard nodes; however, future specifications or proprietary services can define their own nodes for extensibility.
    • -
  • All information sharing within the conversation uses standard PubSub semantics from &xep0060;. There are no special-purpose message or presence stanzas, such as those used to join roooms in MUC.
  • Affiliations with the nodes are, by default, tied together as affiliations on the conversation itself rather than individual nodes, so that allowing or denying access to a conversation is a single affiliation change.
  • &xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).
  • A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.
  • Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them - e.g. 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.
    • -
  • In the context of a conversation, each participant is addressable by a stable participant identifier or "PID" that is assigned by the MIX service. This PID is an opaque identifier (such as a UUID) that an be supplemented by a human-friendly "handle" (equivalent to a nickname in MUC). Note that MIX decouples addressing of participants from their handles, so that changes to handles don't modify addressing.
  • A user's participation in a conversation outlives their presence session. A user who is offline will not share presence within the conversation, but will still be listed as an participant. This too is a significant departure from MUC.
    • +
  • MUC2 decouples addressing of occupants from their nicknames, such that nickname changes don't affect addressing, adding flexibility.
    • +
  • Each occupant is addressible by a single JID - in non-anonymous rooms these are just the ocucpant's 'real' JID such that messages between users are only mediated by the MUC2 service in semi-anonymous rooms. These are full JIDs, allowing transparency when a user has multiple online resources participating in the MIX.

    • MIX is based upon domains providing a MIX service, such as `mix.shakespeare.example`. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. (Note that, like in MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service is purely an example).

    -

    Every MIX conversation is an addressable PubSub service (with additional MIX semantics) that will be addressed by an XMPP client using a bare JID, for example coven@mix.shakespeare.example. Other than the special "join" command, all communication with the MIX service follows &xep0060;.

    +

    Every MIX conversation is an addressable PubSub service (with additional MIX semantics) that will be addressed by an XMPP client using a bare JID, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, some protocol is added or optimised in this document for the MIX use cases. For example, when a message is published to the 'urn:xmpp:mix:nodes:messages' node, a message unlike a &xep0060; payload is distributed to occupants (more akin to the old &xep0045;); this enables standard XMPP semantics of message stanzas to be used.

    Message Archive Management is used for all storage of historical data (such as the history of messages sent within the conversation). Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve information archived in MAM in order to quickly resync with regard to a conversation, and can do so without necessarily providing presence information.

    @@ -95,7 +95,7 @@