[Standards] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM
flo at geekplace.eu
Sun Jun 3 10:07:23 UTC 2018
On 03.06.2018 11:48, Florian Schmaus wrote:
> 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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards