[Standards] Using route-able JIDs in MIX-CORE

Florian Schmaus flo at geekplace.eu
Sun Jun 3 16:27:20 UTC 2018

On 03.06.2018 18:01, Steve Kille wrote:
>>> That very much looks like that I would currently favour, besides that
>>> I don't see a reason why we shouldn't also use the stable participant
>>> identifier as the resourcepart of the originating address.
>> Uh, and I slightly favour presence also from
>> channel at mix.service/stable-participant-id/unique-client-id
>> as otherwise you will get presence from different devices from the same
>> address. But presence from users with multiple devices is not trivial anyway, not
>> only in the context of MIX, so no matter what we do, someone has to handle it. I
>> still prefer keeping the invariant that presence comes from a unique address per
>> user session, because I think it has the potential to make things easier.
> [Steve Kille] 
> This is an important point.    All of the information needed is carried in the message.    So a change like this does not provide any more information to the final recipient.
> However, it means that the JID will be unique for each sending client.   This can facilitate an implementation handling JIDs internally, by enabling sensible switching of messages.
> If we do this,  I think that it makes sense (for similar reasons) to have messages sent from a JID that uniquely identifies the sender of form:  channel at mix.service/stable-participant-id
What exactly do you mean with "uniquely identifies the sender"? The
sending entity? Or a concrete XMPP session of the sending entity?

Where are possibly a little bit ouf of sync here. Therefore I try to
summarize the approach I currently champion:

1.) message stanza originate from channel at mix.service/stable-participant-id

Rationale: The tuple of channel, service and stable participant id
consists of the most valuable information of message receiving entities
in the context of persisent groupchats. The unique client id,
identifying the concrete sending client(/user session) can be put as
(possibly optional) metadata into an extension element of the message.

2.) presence stanzas originate from
channel at mix.service/stable-participant-id/client-id

To keep the invariant that distinct from addresses in presence stanzas
represent distinct clients(/user sessions).

3.) IQ requests usually send to / received from
channel at mix.service/stable-participant-id/client-id

To allow us to address a particular client for IQ exchange. (We could
add IQ semantics for channel at mix.service/stable-participant-id later on,
but I'm undecided yet if it is a good idea)

Bonus points if:
- Messages send to channel at mix.service are standard groupchat messages
- Messages send to channel at mix.serivce/stable-paticiapnt-id are send to
a participant (PMs, e.g. fan-out via carbons, most available resource, …)
- Messages send to channel at mix.service/stable-participant-id/client-id
are send to single XMPP session of the participant identified by
client-id (IBB (?)).

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180603/fe1bd988/attachment.sig>

More information about the Standards mailing list