[Standards] MIX Addressing
kevin.smith at isode.com
Fri Jun 1 16:27:58 UTC 2018
On 1 Jun 2018, at 17:19, Florian Schmaus <flo at geekplace.eu> wrote:
> On 01.06.2018 17:57, Kevin Smith wrote:
>> On 1 Jun 2018, at 16:47, Florian Schmaus <flo at geekplace.eu> wrote:
>>> On 31.05.2018 13:45, Kevin Smith wrote:
>>>> We’ve had some discussions recently about whether presence should come from the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly whether messages should be coming from the channel’s JID or the user’s proxy JID. I think the argument that things should come from the user’s in-channel JID rather than the channel’s is reasonable - this is also what happens already in MUC and is familiar.
>>>> The reason for the proxy JIDs is that we need a stable identifier for the user in the channel,
>>>> and we need it to be addressable per client.
>>> Why was that again? Do we really need to encode four bits of information
>>> in a single JID?
>> IQs, mostly, they need to be address translated to the user’s full JID, which means encoding the full JID and the channel into the initial ‘to’.
> But that only means you need a way to retrieve a JID which acts as proxy
> JID for the user's real full JID. Not that MIX messages have to
> originate from such an address. Right?
Indeed, that’s exactly what option 4 is suggesting. Messages from the channel would come from channel at domain/user. There would also exist user#channel at domain(/resource) that can be used for directly routing stanzas (e.g. PM or iq).
>>> <message from="channel at mixservice.domain.example/user"
>>> to="user at other.example" …>
>>> <mix-message sender-resource="b481e03f-c633-4704-a877-f8222eb02bc7"/>
>> That looks rather like option 2, with the added resource payload (which is probably not needed?). Option 2 sees messages sent from channel at domain/user. Presence is different (but you note looking at the presence node for full-JID information here as well).
> It sure is similar. I just wonder if MIX channels need to send
> participants presences from a JID that encodes all four bits of
> information (similar to what Steve suggested).
They need encoding somehow, certainly. So you either encode all four parts of addressing into the JID, or you encode three into the JID and then encode the fourth part into the payload somewhere - which is possible, but seems somewhat perverse to be using stanza payloads for addressing rather than the JID.
> Alternatively: Why do MIX channels need to send presence status of
> *participants* as "standard" presence stanzas? Instead interested
> parties could retrieve presence updates via standard pubsub push
> messages (If I read xep403 correctly, presence information is already
> stored in PubSub nodes).
It’s clearly *possible* to do everything entirely over 60 and throw away the primitives (207 does show it’s possible, after all, even if it’s humorous), but there seems to be merit in using the primitives where we sensibly can (especially as presence has helpful properties like bypassing archives and the like).
More information about the Standards