From 8f933bc919afc11d74efdb937d58bd2f1cffc55d Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Wed, 5 Oct 2016 15:34:40 +0100 Subject: [PATCH] Channel Invitations --- xep-0369.xml | 139 ++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 103 insertions(+), 36 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index af0cea25..d678ddc7 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -480,7 +480,7 @@
  • 'JID Visibility'. Choice of "jid-hidden", "jid-optionally-visible", "jid-mandatory-visible".
  • 'Open Presence'. If selected, any client may register presence. If not selected, only clients with bare JID in the participants list may register presence.
  • 'Allow Message Retraction'. If this option is selected users will be able to retract messages sent to the MIX channel.
    • -
  • 'Participation Extension by Invitation'. This option extends a channel so that an invitation from a channel participant will add the invited user to the allowed list. +
  • 'Participation Addition by Invitation from Participant'. This option extends a channel so that a channel participant has rights to invite and enable other users as participants.
  • 'No Private Messages'. If this option is selected, private messages may not be used with the channel.
    • @@ -1293,50 +1293,117 @@ the participant is not be subscribed to all nodes associated with the channel (i

    - +

    A convenient way to reference another channel is to use &xep0372; which enables the JID of a channel to be shared. This might be used simply to inform the message recipient about the channel or as mechanism to invite the user to join the channel. This is useful as an invitation mechanism to a channel that any user can join or where the invitee knows that the user may join (e.g., because the channel is for all users in an organization).

    - -

    When a channel participant invites another user to join a channel, a sequence of steps are followed. + +

    Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel may have a special mode where channel participants may grant rights for other users to join a channel ('Participation Addition by Invitation from Participant' enabled). This approach is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation. + + + When a channel participant(the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:

      -
    1. The channel participant sends to the channel requesting an invite for the user.
      2. -
    2. The channel sends an invitation to the user requesting the invite.
      3. -
    3. The channel participant sends the invitation to the invitee.
      4. -
    4. The invitee uses the invitation to construct a request to join the channel.
      5. +
    5. The channel inviter sends to the channel requesting an invite for the invitee.
      6. +
    6. The channel sends an invitation to the inviter.
      7. +
    7. The inviter sends the invitation to the invitee.
      8. +
    8. The invitee MAY use the invitation to join the channel.
      9. +
    9. The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.
    -

    AUTHOR'S NOTES AND QUESTION: Need to consider including declines. To be expanded considerably and perhaps modified based on the following: Dave Cridland notes: - > There are three actors - the participant (who is the inviter), the Invitee, and - > the Channel. - > - > A) The participant obtains an Invitation (containing a verifiable token) from the - > Channel. This allows the Channel to reject attempts to invite users who - > should not be able to join the channel, but it might provide the token anyway - > to avoid probes discovering who is allowed to join the room. This is your step - > 1. - > - > B) The participant sends this Invitation (including the token) to the Invitee. - > (Step 2) - > - > C) The Invitee can optionally request from the Channel the validity of the - > Invitation. (Not included) - > - > D) The Invitee can use the Invitation. (Step 3) - > - > The idea behind my step C is that it allows a client to validate that the entity - > sending an invitation really is a participant of the channel, and could - > legitimately act as a participant. This could be folded into (D), although it - > depends on whether we want to present the Invitation without knowing its - > validity. - > - > It feels as if an Invitee executing on an Invitation ought to be able to tell if the - > Invitation was genuine or not. - > - .

    +

    + The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel has 'Participation Addition by Invitation from Participant' mode enable. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. +

    + + + + cat@shakespeare.lit + + + + + + + hag66@shakespeare.lit + cat@shakespeare.lit + coven@mix.shakespeare.lit + ABCDEF + + +]]> + +

    + The inviter can now send the invitee a message containing the invitation, as shown in the following example. +

    + + + Would you like to join the coven? + + hag66@shakespeare.lit + cat@shakespeare.lit + coven@mix.shakespeare.lit + ABCDEF + + +]]> + + +

    The invitation can now be used by the invitee to join a channel. The invitation is simply added to the standard channel join, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.

    + + + + + + + hag66@shakespeare.lit + cat@shakespeare.lit + coven@mix.shakespeare.lit + ABCDEF + + + +]]> + +

    The invitee may send an acknowledgement back to the inviter, noting the status of the invitation. Values are:

    +
      +
    • 'Joined': The invitee has joined the channel.
      • +
    • 'Declined': The invitee is not taking up the invitation.
      • +
    • 'Acknowledged': The invitation is acknowledged, without information on action taken or planned.
      • +
    + + + No Thanks - too busy chasing mice.... + + Declined + + hag66@shakespeare.lit + cat@shakespeare.lit + coven@mix.shakespeare.lit + ABCDEF + + + +]]> +