[Standards] MIX Addressing

Jonas Wielicki jonas at wielicki.name
Fri Jun 1 08:20:50 UTC 2018

On Freitag, 1. Juni 2018 09:29:15 CEST Kevin Smith wrote:
> > So here’s a straw-man proposal, Variant 3 (because, creating many variants
> > is what we’re good at!):
> > 
> > An occupant is identified by an occupant-identifier. The occupant JID is
> > occupant-identifier at mix-service. The channel to which a message belongs is
> > 
> > identified with a payload item. Example message:
> >  <message type="groupchat"
> >  
> >           from="4973d5d365f8 at mixservice.domain.example/client-resource"
> >           to="user at other.example">
> >    
> >    <mix channel="some-channel"/>
> >    <body>...</body>
> >  
> >  </message>
> > 
> > Advantages:
> > 
> > - No re-write of resources needed (good for MIXes)
> > - Bare JID refers to occupant identity (good for clients)
> > - Servers can simply filter on message/mix/@channel (not perfect, but
> > better than requiring a new JID processing function)
> > - Opens up the possibility of re-using the same proxy JID for the same
> > occupant across different channels (may be useful in some deployments, via
> > MattJ)
> > - No non-RFC6122-based operations required on JIDs.
> > 
> > Disadvantages:
> > 
> > - All (including 1:1) stanzas exchanged between occupants require the <mix
> > channel="…"/> element for MIX channels to be able to easily route them
> > - Entities filtering on MIX channel identity still need to know about MIX
> > (and the <mix channel="…"/> element)
> > - The namespace of MIX channel JIDs and occupant JIDs needs to be
> > separated in some way. This can be achieved with a single bit, so a
> > forced prefix on occupant JIDs (and a forbidden prefix on channel JIDs),
> > such as "%", would work for that. (I’m not sure if we would have to
> > standardize the method by which services do this split.)
> > 
> > 
> > What do you folks think?
> I don’t want to go as far as saying I hate it, but I certainly don’t like
> it, I think it’s the worst of the three (now four) options. It completely
> removes all context from the header, and you have to go snooping inside
> every packet to work out where it’s really from (

> because for almost all
> processing concerns it’s the channel that’s regarded as the sender, not the
> originator

See, here’s where I disagree. In the client, the only processing which is 
based on the channel is the first fanout to distribute it to the right 
conversation window. Everything afterwards is very much concerned with the 
occupant identity. I think that this is the discrepancy between server and 
client concerns I was talking about.

> ). Now your archive will be completely broken without quite
> excessive DPI on the MAM server, 

This is a good point (selecting MAM from a MIX channel is now hard). I didn’t 
consider this because my MAM workflow is a "sync everything" one, so I 
wouldn’t care. However, I know that this isn’t the only workflow and a way to 
select messages from a MIX channel is important.

How would that work with Variant 1?

> and your client’s internal routing is no
> longer straightforwardly hierarchical based on the from.

That would only be the case with Variant 2 anyways. I see the appeal of 
hierarchical routing, but I’m not quite ready to let go of "equal bare JID 
implies equal identity". This has been one of the things I looked forward to 
most in MIX (as a client developer).

> You’re also
> opening the door to fun types of exploits (as now you’ve got an entity
> saying “My routing information says I’m coming from X, but really I’m from
> Y, honest” and you need protection against this throughout the system.

Also very good point against Variant 3.

> I appreciate trying to come up with better solutions than 1/2 (neither of
> which is ideal) and the space is complicated, but in this case I very much
> don’t think this is the best option.

I tend to agree.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180601/d75638c5/attachment.sig>

More information about the Standards mailing list