Dave,
> -----Original Message----- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Dave > Cridland > Sent: 15 March 2017 10:54 > To: XMPP Standards > Subject: [Standards] MIX, MAM, jidmap, and Jid-Hidden > > Folks, > > [This is long, sorry, and has a series of smaller points near the bottom, feel > free to skip down] > > As you may be aware, jid-hidden is a particular driver for our use of MIX. So, > too, is historical access to MIX messages, since we're building an > asynchronous message board type thing. > > Currently, a message to MIX always ends up with the Proxy JID: > > <message ...> > <body>Foo!</body> > ... > <jid xmlns='mix:0'>proxy+jid@mix.example</jid> > </message> > > If you'd like to know who that proxy jid belongs to, you can look in the jimap, > if it's available (to you). > > So far, so good - albeit arguably a bit over-complicated. Since we don't > actually use the proxy jid in addressing of MIX groupchat messages, it's just > an opaque identifier which might not be opaque. > > So you come back later, and want to catch up in MAM. You'll get the same > message (wrapped in <result/> and <forwarded/>). In order to figure out > whose proxy jid this *was*, we now have to poke about with MAM on the > jidmap. We need to find the proxy jid item as it was at a particular point in > time. Which isn't easy - you need all the events between the Dawn Of Time > and the message timestamp, I think. Or we could have MAM have a new > "show me the state of this node as it was at this timestamp", but then we'd > have to do this with every message. And you might, legitimately, not find it. > > This is, I think, more complicated than it needs to be. > > Instead, it could do: > > <message ...> > <body>Foo!</body> > ... > <jid xmlns='mix:1' type='proxy' > state='hidden'>proxy+...@mix.example.net</jid> > </message> > > Then you'd know that you have a proxy jid, and it's hidden, so don't bother > looking it up. > > You might also get: > > ... > <jid xmlns='mix:1' type='real' state='hidden'>real@domain.example</jid> > ... > > Then you'd know that while you can see the real jid (maybe you're an > admin?), the user requested it be hidden. > > The combination of type='proxy', state='visible', would not occur - if you can > see the real jid, it would be present. And if you can see the real jid, do we > ever want to see a proxy? (if we do, we'll need simply an optional element > containing real jid). [Steve Kille] 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. 2. It gives problems with changing between JID visible and JID hidden (your point below). 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='coven@mix.shakespeare.example' to='hecate@shakespeare.example' 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'>coven+123456@mix.shakespeare.example</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. > > 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. > > 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. > > 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. > > 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. > > 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: standards-unsubscr...@xmpp.org _______________________________________________
