[Standards] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM

Florian Schmaus flo at geekplace.eu
Sun Jun 3 09:48:27 UTC 2018

On 03.06.2018 01:33, Steve Kille wrote:
> Sam's message made me realize that none of the variant 1/2/3/4 stuff is
> needed for MIX-CORE.    There are some things that might be needed in
> MIX-ANON, but let's worry about these in the MIX-ANON spec and keep them out
> of MIX-CORE.
> In MIX-CORE, messages/presence go to a channel or are distributed by a
> channel.  There is no participant to participant (PM style) communications.
> I suggest.
> 1.  Messages come from the channel  (channel at domain).   This is what is
> happening as the channel is distributing messages.  Inside each message you
> have a mandatory sender information: (Nick and Bare JID).   There would be
> an elegance to putting this information into the JID, but I do not think it
> is practical and it does not gain you anything.
> 2.  Presence come from the channel  (channel at domain).   This reflects that
> the channel is distributing presence.  Inside each presence stanza you have
> a mandatory sender information: (Nick and Full JID).   
> That is it.   Very simple.   No variant JID addressing.  There are some
> issues for MIX-ANON, but lets worry about these in MIX-ANON, and not make
> the core more complex than it needs to be.

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.

Further metadata, like nickname, unique client id (or whatever it is
called), can be put into a extension element of the message and presence

Sending IQs would require a lookup of the address of desired
participant's device which would yield something like
channel at mix.service/stable-participant-id/unique-client-id

That also means that you could send messages either to all devices of a
participant via

channel at mix.service/stable-participant-id

or to a particular devices of a participant

channel at mix.service/stable-participant-id/unique-client-id

e.g. for IBB and the like.

- 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/af2b1efe/attachment.sig>

More information about the Standards mailing list