On 15 March 2017 at 17:46, Kevin Smith <[email protected]> wrote: > 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.
I confess we don't care about Nicknames. I confess I might not, generally, care about nicknames for non-anonymous users, and might think they're a weirdness that we'd be best avoiding in such cases. That's not saying I'm arguing for removal, but I'm not considering these with the same attention. > 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. > Yes, we were thinking we'd have to write in the MAM "bits" on MAM result generation time. We can do that easily enough, and for future overlay of a MUC protocol interface, it makes sense. >> >>> 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. > I agree with "a bit". I'm not convinced it's more than "a bit", though - I don't think we're into the realms of "a lot". >>> 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. > Ah. We thought about that for all of two minutes. We have, in a typical MIX channel, around 5-20 messages, written by around 2-5 participants, with some 1,000 people reading. They pretty much have to join, in order to get the push updates we want. Again, I think this is one of those cases where MUC-style usage wouldn't be so onerous. But even then, I wonder how many unique bare jids have ever joined jdev? As for harvesting the jidmap node as and when we can, based on archiving retention - so yes, we could do that, but the tricky problem here is that the messages are labelled, and we don't want to reveal if a participant has posted a message that the current querying user cannot see... (Even if we normally post all messages with the same label). Of course, if we encode the proxy jids such that the bare jid is reversibly encrypted, we could avoid the storage, but that feel like it'll get ugly quickly, and a get-items on the jidmap node will still retur >>>> 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. > Excellent. >>>> 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. > Good. >>>> 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? Just feels nasty. I do think that any change of options regarding privacy is going to be worrying - this case does not scare me nearly as much as the case where users change their own options instead of rejoining, however. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
