I’ve not done the research I should have before responding to this, so apologies if what I say is patently stupid.
> On 15 Mar 2017, at 14:36, Dave Cridland <[email protected]> wrote: >> 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. I prefer the conceptual approach of “There is a single stable identifier for a participant of the MIX, and it’s the proxy JID”. Otherwise you end up needing to have mappings both from full JIDs and proxy JIDs to Nick in the Nick node, and it gets a bit complicated. Even at the expense of extra lookups sometimes. Having different messages for people who can see the JIDs and people who can’t also seems to make things a bit complicated at MAM time. > >> 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? I think it makes the MAM querying a bit fiddly, for the same reasons above. >> 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. I *think* it is sufficient to be able to query the particular item in the jidmap node, isn’t it? That means a server has to keep old mappings around, but I think it’s reasonable to limit that to keeping them around for as long as the archives are kept around. >>> 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. I don’t see a problem here. >>> 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. Proxy JIDs can’t be reusable, I think that’s clear. Whether it’s stable between joins sounds like a deployment question (I would be inclined to say ‘yes’ in the general case, because if you accidentally unjoin a room and rejoin you’re still you. >>> 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. There’s presumably an interaction here with “Don’t reveal my JID” joins that needs describing, more than anything fundamental? /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
