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@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@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@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@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@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@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@mix.service are standard groupchat messages - Messages send to channel@mix.serivce/stable-paticiapnt-id are send to a participant (PMs, e.g. fan-out via carbons, most available resource, …) - Messages send to channel@mix.service/stable-participant-id/client-id are send to single XMPP session of the participant identified by client-id (IBB (?)). - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
