[Standards] Requirements for "Jid Hidden" Channels

Kevin Smith kevin.smith at isode.com
Mon Jun 4 10:13:52 UTC 2018


On 2 Jun 2018, at 17:36, Steve Kille <steve.kille at isode.com> wrote:
> It is clear that much of the complexity around JID encoding that is being
> postulated as necessary, ties back to requirements to support participant
> communication through  JID Hidden channels.
> 
> This note is to step back from the JID discussion, and consider JID Hidden
> channel requirements.   
> 
> I'm writing out a list of requirements here, which I think when agreed,
> could be usefully used as part of the introductory material to MIX-ANON.
> 
> With JID Visible channels,  real JIDs are shared and participants can use
> this to communicate directly.

I think that’s at the core of the issue with where the addressing/routing rules go - if it was true then moving them out into mix-anon would make sense, but I don’t believe it is. Because the current state of the network is that stanzas from entities not in your roster/not a room you’re joined to are very often blocked for spam reasons relying on real JID routing to enable communication between MIX participants is unlikely to work and that we’ll need the routing and addressing logic in core because of this. This is only the very basic routing/addressing logic and all of the anon-related stuff remains in mix-anon.

> When looking at MIX requirements, quite a few argued that we should not have
> JID Hidden.  A lot of other chat systems (e.g., Facebook) do not have an
> equivalent of JID Hidden.   I think that many channels will be JID Visible.
> 
> 
> It was agreed clearly that we need JID Hidden, primarily to prevent JID
> Harvesting.   This is going to be useful for public and semi-public
> channels.
> 
> REQUIREMENTS:
> 
> 1.  Participants can see which other participants have one or more online
> clients.   
> 
> 2.   Online participants can be displayed with a Nick.
> 
> 3.   Participants MUST be able to see if another participant changes Nick.
> 
> 4.    Participants can sent messages to other participants through the
> channel if channel policy allows this.

That’s the one that we fail with.

> 5.    A participant can share real JID with another participant and request
> real JID.   Can't do this currently, but it seems sensible to allow a pair
> of willing participants to shift from restricted communication through the
> channel to direct communication.   

Is that really a requirement? It might be, but also sharing the JID manually seems like a sensible sort of thing to do (I could be persuaded, but I don’t see this really as a core requirement currently)

> POSSIBLE REQUIREMENTS:
> 
> 6.   Participants can share presence status additional to online/offline.
> I am wondering if, in an environment where JIDs are being hidden, if it
> makes sense to share other presence stuff with  the channel.   My sense is
> that for a public MUC, it might make sense to restrict.   I would vote to
> make this a non-requirement.

It might make sense to restrict it in some cases, but not in the general case, I think.

> 7.   Where a participant has multiple clients, other participants can see
> independent status of these clients.   I think that this is not appropriate
> for JID Hidden channels.  If you are not sharing your JID, it feels wrong to
> be sharing how many clients you have.

I’m not sure about this.

> NON REQUIREMENTS
> 
> 
> 8. vCard.   If you are hiding your JID,  it seems wrong to allow retrieval
> of generic information about you.   I think that getting vCard information
> about other participants should be explicitly excluded.
> 
> 
> 9.  Client Disco.   I think that allowing clients to use IQ disco of JID
> Hidden participants is wrong.  If you feel that JID should be hidden, it
> does not make sense to 

Except that we rely on disco/caps for basic functionality, so this seems hard to avoid. There may be specific channels where it’s appropriate to block this (just as direct interactions are blocked in specific channels in MUC at the moment), but I don’t think that’s true in the general case.

/K


More information about the Standards mailing list