On 15 March 2017 at 14:02, Steve Kille <[email protected]> wrote: > What you are suggesting here is that messages for "JID hidden" and "JID > visible" channels are treated differently, and that you distribute real JIDs > in JID visible channels. This was discussed and I was persuaded that this > was not a good idea for two reasons: > > 1. By having different models you need different code paths, and this is a > bad idea. >
We don't seem to, or at least we apply a set item of logic either in the message (and MAM) rendering, or else in each jidmap access - there is no additional logic required, the same logic just moves. > 2. It gives problems with changing between JID visible and JID hidden (your > point below). > I don't think this makes any difference, perhaps you could expand? > Your idea here also shows that treating them differently would add extra > complexity. > > I am unconvinced that your suggestion is sensible. Happy to hear views of > others. > > I note that a typical message with share the Proxy JID and the Nick. > > <message from='[email protected]' > to='[email protected]' > id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' > type='groupchat'> > <body>Harpier cries: 'tis time, 'tis time.</body> > <nick xmlns='urn:xmpp:mix:0'>thirdwitch</nick> > <jid xmlns='urn:xmpp:mix:0'>[email protected]</jid> > </message> > > > When a user gets such a message back from MAM, displaying the nick seems > sensible (and generally helpful to the end user). If there is a desire to > communicate with the user, a PM through the channel using the proxy JID will > work fine. > > Lookup of the real JID (if allowed) needs a few operations, but I don't > think will need to be done very often. > Unfortunately, we're dealing entirely with either the "real" identity or else a stable pseudonym; we're not "decloaking" users on request but continuously. I think this matches what one would do in any "social" application. If you can explain how one can tell what the real jid is given a historical message, I'm all ears, but short of downloading the entirety of the jidmap archive, I couldn't see how. > >> >> Also... >> >> 1) Section 3.9.5 is wrong, since it says, "The JID Map node MUST have one >> entry for each entry in the Participants node." Where a participant has > set >> jid-hidden, this is not so. > [Steve Kille] > > I think that the statement is correct. Channel Administrators and Owners > need to know the real JIDs. The channel needs to know the real JIDs to > distribute the message. Visible and Hidden is reflected in who has > access to this node. > > I think you mean "where a participant has set preference to Prefer Hidden" > ("JID hidden" is a channel state, not a user state). > > On looking at this, support of "Prefer Hidden" has not been worked through. > To make this work, I think you need to add a new node, perhaps "Participant > Visible JID Map" that is visible to participants and holds the map for > participants who have not set "Prefer Hidden". > > My immediate thinking is that we should drop "Prefer Hidden", but I can add > the new node if people think this capability is important. > We really need per-user visibility controls. If MIX doesn't provide this, we'll have to add them in, and moreover, if this results in something incompatible with MIX, we'll just have to be something other than MIX, which seems a real shame. But the jidmap surely just has per-item access control - I don't see how this is a problem. This is how we interpreted the specification - that running a get-items over the jidmap would show different users different items - and that much works fine. > >> >> 2) Section 6.1.3 is problematic too - perhaps this doesn't matter, but if > a >> proxy jid has been openly associated with a particular real jid, then > hiding it >> later doesn't seem to be very effective. It seems to be that we would want >> users to leave, and rejoin under new options (and a new proxy jid). > [Steve Kille] > > > If a channel goes from JID visible to JID hidden, someone who knows the old > mappings will continue to know them. So if a user wants to hide, they will > need to rejoin and use a different nick. > > This does not seem a big deal. > This is specifically about the user's control, not changing the channel configuration. You're therefore agreeing with me. :-) Changing join options seems fraught with issues. I'd happily see this go. > >> >> 3) Is is unclear what the long-term associativeness between a given proxy > jid >> and real jid is. Can a proxy jid be associated with different real jids at >> different times (I'd like this not to be the case)? Can a given real jid > be >> mapped to multiple proxy jids at different times? (Probably needs to be, > see >> above). > [Steve Kille] > > 3.8 has some constraints. In particular, the mapping between bare proxy > JID and real JID must not change. > > If a JID leaves and joins again, I think it would be impractical to require > that the JID gets the same proxy JID. I can see reasons why it might be > desirable and reasons why it might not be. > > I will add some text on re-use of proxy JIDs. My inclination is to mandate > that they are not re-used. As you note, this is not desirable, and I can > see a straightforward way for an implementation to achieve this. > This would be OK. I would note that having proxy jids stable on a given input jid and visibility state is also trivial (just HMAC the inputs with a secret key). But this can be an implementation choice. > >> >> 4) It's also unclear if configuration is retrospective where possible >> - does changing a channel from jid-visible to jid-hidden at time t=0 > affect >> future MAM queries covering periods t<0? Or would messages until t=0 be, >> essentially, seen as jid-visible? (I don't care, but consistency would be > nice to >> at least SHOULD level). > [Steve Kille] > > By only having proxy JIDs in messages (as I believe is sensible) this comes > down to MAM access to the JID MAP node archive. > > I think that the model of MAM access is based on user rights. I don't know > what MAM says about use of historical or current rights. Whatever MAM says, > I want MIX to use this. > Ah, so this is interesting. If access to a static jidmap is the only criterion, then making a channel jid-visible would simply change access control on jidmap, and - therefore - expose the real jids of all previous occupants of the room to anyone who asks. I'm not entirely sure you want this; it feels like a horror story waiting to happen. > >> >> As a final note, the MIX implementation in Openfire is progressing nicely, >> though we're missing things like Presence at the moment - early >> experimentation is welcome, please nudge me if you want pointers to the >> code. > [Steve Kille] > > Excellent news. > > >> >> Dave. > > [Steve Kille] > > > Steve > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
