Re: [Standards] Obsoleting vCard-Based Avatars
On 08/01/2017 14:59, Sam Whited wrote: Hi all, XEP-0053: vCard-Based Avatars [1] is a historical specification that has been superseded by XEP-0084: User Avatars [2] for quite some time. However, since it's historical it still shows up in the list on xmpp.org and this seems like a possible source of confusion to me. I'd like to propose that we move 0053 to "Obsolete" officially. We could also mention in 0084 that it may be a good idea to implement it in a read-only fashion (as Conversations does) for backwards compatibility, but that new full implementations aren't recommended. Thoughts? FWIW, give the remaining widespread deployment of vcard avatars compared to pubsub-based, and of reported lack of interop between 84 implementations (I'm sure I remember being told that some clients aren't sending mandatory formats), it seems premature to me to obsolete these. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0369 (MIX) - update to 0.6.5 - to address client interaction with MIX Proxy
I have just submitted the PR An update to address MIX proxy handling following discussion with Daniel and input from my co-author. 6.3 is now modified so that when a client sends a JOIN, it sends a message to the user's own bare JID. This is preferable, as the server is explicitly addressed (rather than the previous text which required magic interception) Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] MIX Discussion topics for the Summit - update #2
I've updated this list of questions to reflect various discussions and that MIX 0.6.4 has obsoleted two of the questions. I would encourage review looking to identify further topics for discussion. Discussion of topics before the meeting is fine, but key focus should be to build the list, not resolve items on the list. This is based on 0.6.4 of MIX.I may well make further MIX edits before the summit, particularly if straightforward or editorial points arise. I am choosing to include my views on the answers (marked SEK). I hope that this is seen as helpful. Q1. Should we retain MIX Subject? SEK: The spec currently supports XEP-0045 style Subject. Subject reflects a style of Room use where the discussion topic is set and changed in line with the discussion by moderators or participants. This does not reflect the type of room usage I observe or use in modern real time chat services such as Slack.I think that use of Description (MIX information node) would be a better way of handling the way I see subject used (e.g., XSF subject is the fairly static: " XSF discussion room | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings | XMPP Summit: sum...@muc.xmpp.org").So, I would suggest that we drop Subject, unless a significant real use requirement is identified. I do not think we should retain it simply for MUC backwards compatibility. Q2. Should we include Voice Control? SEK: I have explicitly excluded voice control, although it would not be hard to add in. I believe that this belongs to a type of room use that simply does not happen. If we choose to retain Subject and identify requirements, I think it makes sense to consider if we want voice control. I feel that this is a bit of complexity that MIX can do without. Q3. Should we allow password controlled rooms? SEK: These are not in the current MIX. I think that this is lousy security and we should drop this (the current text reflects this view). If someone really wants this, an additional XEP could be written. I am very strongly opposed to putting this into core MIX. Q4. Should MIX Proxy allow a user's clients to have different channel participation SEK: The current spec allows this and enables clients to select channel membership.This adds flexibility, but I can see merits in a simpler approach of requiring all clients to have the same membership. Q5. Should MIX Channels be added to the roster? SEK: The current spec does this and I think it is a clean and elegant approach, which I would like to retain. It seems to me that it re-uses a lot of core XMPP functionality in a sensible way. Georg Lukas has argued that this function should be in MIX Proxy and roster should not be used. I note that for operation where all clients have same MIX channel use, roster works nicely. If different clients have different sets of channels (see Q5) "correct" behaviour (which I set out in the MIX proxy section) needs MIX specific behaviour for the roster handling. I prefer to address this by allowing roster extension to address this (rather than discarding the whole approach). Q6. Where MIX Proxy is specified and what is the relationship to PAM? SEK: The original intent was to specify all of this in PAM. I wrote a MIX Proxy section in MIX, as I felt it was important to set out what behaviour is needed. This section currently notes that the text might move to PAM or a separate MIX/PAM specification.Looking at the result, I think that it should stay in the MIX specification for now as it is central to how MIX works and there is a good deal of MIX specific stuff in it.A decision on this may need to be deferred until further work has been done on PAM. Q7. What should we change the name "MIX Proxy" to? SEK: I introduced MIX Proxy as a term to group and make very clear behaviour of the User's Server which is important to MIX. It is essential to draw this out clearly as this requirement is not intuitive.This is a behaviour of the User's Server and one way to address this is simply to now describe as "MIX behaviour of the User's Server".Or we could find a special term for the behaviour such as "MIX Behaviour of the User's Server" (or something snappier).I think it is important that we describe in a way which does not give the sense of some sort of separate entity. Q8. Do we need to support JID hidden channels and proxy JIDs? SEK. Some have argued that proxy JIDs add too much complexity to MIX. Proxy JIDs are used to support JID Hidden channels. A little complexity could be removed if we dis-allow conversion between JID hidden/visible, but most of the complexity is inherent to JID Hidden. I do not believe there is a better approach to JID Hidden. The 2016 summit was clear that we need to support JID Hidden (e.g., to prevent JID harvesting in public channels).I think that this means we need to use proxy JIDs. Q9.Should we
Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
On Tue, Jan 10, 2017 at 9:43 AM, XMPP Extensions Editor wrote: > Version 0.6.3 of XEP-0369 (Mediated Information eXchange (MIX)) has been > released. Sorry, that's 0.6.4 that was just published, I'm not sure what failed here. I have verified that the version on the server is correct. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
Version 0.6.3 of XEP-0369 (Mediated Information eXchange (MIX)) has been released. Abstract: This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to provide human group communication and communication between non-human entities using channels, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC). MIX uses Publish-Subscribe to provide flexible access and publication, and uses Message Archive Management (MAM) to provide storage and archiving. Changelog: Add Update and Distribution to Table 3; Correct from in messages from channel; Use XEP-0297 in message forwarding; Update Dependent XEPs (sek) Diff: http://xmpp.org/extensions/diff/api/xep/0369/diff/0.6.2/vs/0.6.3 URL: http://xmpp.org/extensions/xep-0369.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0369 Proxy JIDs and MIX
On 10/01/2017 15:23, Sam Whited wrote: 2. While burner JIDs may be helpful to provide a user with complete anonymity in a channel, I think that channel administration needs access to the real JIDs. It would not be acceptable to manage a public MUC and just have a stack of anonymous participants. So use of client provided burner JIDs is not a viable approach to JID hidden channels. If burner JIDs are allowed on some other server, this happens anyways. It's not something you can prevent. Well, kinda, except that burner JIDs have much the same security properties as SASL ANONYMOUS, so the same considerations apply - these things shouldn't be allowed to S2S, and servers that do allow them to S2S can be blocked at the whole server level (as happens already). /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On Tue, Jan 10, 2017 at 9:23 AM, Kevin Smith wrote: > Except if it's the MIX issuing burners, isn't 'the server' in this case the > MIX server? Which you very possibly can't route to from your client because > it crosses an organisational boundary, and only S2S can get across? Could be either; I've been saying the MIX service, but I suppose you're right, it would have to be the server and the MIX service would be configured to check that JIDs were issued by the service. This does require some shared datastore or public key between them. Either way, I don't think this adds substantial overhead. > Except you need it tracked in your 'real' account, so clients know > connection details for all your burner JIDs, and you need to be jumping > through hoops as a client to do so each login. Yes; I'm unsure how much work this would be for current clients. I suspected that it would be relatively easy, but TBH I'm not sure. > Well, you have to have the clients check too, because otherwise they'll try > to join a room with their real JID and not be allowed because the room's > semi-anonymous. Fair. > Sure, I think MIX's use of proxy JIDs here is exactly doing this better than > MUC did :) > My original proposal to simplify things was to not have semi-anonymous > rooms, but people rapidly let me know that I was being an idiot and we need > this functionality ;) Same here; I didn't want this complexity when we first conceived MIX in Washington, and still think that either way just makes things too complicated (but as you said, I was rapidly overruled). Steve just started a new thread about this; maybe we should take discussion about other alternatives there. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0369 Proxy JIDs and MIX
On Tue, Jan 10, 2017 at 6:11 AM, Steve Kille wrote: > 1.The driving requirement for Proxy JIDs is support of JID hidden > channels. Obviously I am more or less alone in this, but I do not see JID hidden channels as a necessity and think we should just get rid of them. If people want to hide their JID, they can use a burner JID (either the speced kind, or just create a new one on some server, use it, and throw it away). I also do not see this changing, but I wanted to keep this opinion voiced just in case. > 2. While burner JIDs may be helpful to provide a user with complete > anonymity in a channel, I think that channel administration > needs access to the real JIDs. It would not be acceptable to manage a > public MUC and just have a stack of anonymous participants. So use of > client provided burner JIDs is not a viable approach to JID hidden channels. If burner JIDs are allowed on some other server, this happens anyways. It's not something you can prevent. However, if the MIX server implements burner JIDs itself, then you already have a mapping of real-jid to burner-jid that the admins can use to ban the underlying real JID from creating new burner JIDs (because the server had to issue the burner JID, so obviously it knows who it issued it too). Maybe the MIX server disallowing all JIDs but its own burner JIDs would be a more common scenario than I thought in the other thread about this, which does add a tiny bit of extra complexity, but I still think it keeps things simpler than using proxy JIDs. These are mostly server-side implementation details that don't require extra protocol. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On 10/01/2017 15:16, Sam Whited wrote: On Tue, Jan 10, 2017 at 9:01 AM, Kevin Smith wrote: I think you'd need to build so much extra stuff on top of burner JIDs … that you end up with vastly more complexity than proxy JIDs give you. I'm not so sure; you get a burner JID, you make a new connection to the server with it Except if it's the MIX issuing burners, isn't 'the server' in this case the MIX server? Which you very possibly can't route to from your client because it crosses an organisational boundary, and only S2S can get across? , you use it as if it were a normal JID and everything interacts with it exactly the same as it would have done with a normal JID. Except you need it tracked in your 'real' account, so clients know connection details for all your burner JIDs, and you need to be jumping through hoops as a client to do so each login. The only real thing you have to implement is the rules that check if a JID is allowed or not on the server if you *only* want to allow burner JIDs, but that's a special case anyways (since you might as well leave it up to users whether or not to expose their real JIDs at this point). Well, you have to have the clients check too, because otherwise they'll try to join a room with their real JID and not be allowed because the room's semi-anonymous. That being said, I could also see this being true; there's a lot of room for complexity here. I'd like to experiment with some implementations and find out. I think there might be a certain amount of optimism involved here in how much is needed to replace proxy JIDs with burners. By all means try to write up how burners would work :) Proxy JIDs are very similar in complexity to how MUC currently works, where you use a room-assigned (although client-requested) anonymising JID. I don't think anyone has problems with dealing with these concepts for MUC, and I don't think they will for MIX. I feel like this is one of the concepts that bothers me most about MUC (and causes many of my implementation headaches), probably second only to presence being tied to membership. I agree that they're similar levels of complexity, but I still think we can do better than MUC did in this regard, even if burner JIDs aren't that way. Sure, I think MIX's use of proxy JIDs here is exactly doing this better than MUC did :) My original proposal to simplify things was to not have semi-anonymous rooms, but people rapidly let me know that I was being an idiot and we need this functionality ;) /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On Tue, Jan 10, 2017 at 9:01 AM, Kevin Smith wrote: > I think you'd need to build so much extra stuff on top of burner JIDs … that > you end up with vastly more complexity than > proxy JIDs give you. I'm not so sure; you get a burner JID, you make a new connection to the server with it, you use it as if it were a normal JID and everything interacts with it exactly the same as it would have done with a normal JID. The only real thing you have to implement is the rules that check if a JID is allowed or not on the server if you *only* want to allow burner JIDs, but that's a special case anyways (since you might as well leave it up to users whether or not to expose their real JIDs at this point). That being said, I could also see this being true; there's a lot of room for complexity here. I'd like to experiment with some implementations and find out. > Proxy JIDs are very similar in complexity to how MUC currently works, where > you use a room-assigned (although client-requested) anonymising JID. I don't > think anyone has problems with dealing with these concepts for MUC, and I > don't think they will for MIX. I feel like this is one of the concepts that bothers me most about MUC (and causes many of my implementation headaches), probably second only to presence being tied to membership. I agree that they're similar levels of complexity, but I still think we can do better than MUC did in this regard, even if burner JIDs aren't that way. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0369 (MIX) - two more updates slipped in to 0.6.4
I put in two more updates. The first is to return proxy JID on channel join. The second makes changes to message reflection Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]
On 06/01/2017 16:15, Sam Whited wrote: On Fri, Jan 6, 2017 at 10:10 AM, Steve Kille wrote: I don't object to this, but I can't see how it makes much difference to MIX. What impact is there besides following the rules for generating random JIDs? Using this removes the need for semi-anonymous channels and proxy JIDs, which will simplify the MIX spec a lot. It shifts the decision about whether or not a user is anonymous from the MIX service to the user since they can decide whether or not to use a burner JID before joining any channels (although the MIX service would still be able to enforce that a room be anonymous by only allowing in JIDs issued by its own burner JID service). I think you'd need to build so much extra stuff on top of burner JIDs (e.g., exposing real JIDs to admins, configuration so only your own burners can be admitted, users' clients checking if a room needs them to register a burner, and then registering it, and then joining the channel, working out how this all interacts with PAM, working out how this interacts with MAM, ensuring activation of burner JIDs 'just works' on login without additional steps, defining ways to bind burners into the same stream as all other traffic, to name just a few of of them) that you end up with vastly more complexity than proxy JIDs give you. Proxy JIDs are very similar in complexity to how MUC currently works, where you use a room-assigned (although client-requested) anonymising JID. I don't think anyone has problems with dealing with these concepts for MUC, and I don't think they will for MIX. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain
On 10 January 2017 at 14:37, Kevin Smith wrote: > > > On 10/01/2017 14:27, Dave Cridland wrote: >> >> On 10 January 2017 at 13:30, Kevin Smith wrote: >>> >>> On 10/01/2017 12:05, Steve Kille wrote: I have just issued a PR for MIX version 0.6.4. There is clear desire to have the option for MUC and MIX to use the same domain.The difficulty in achieving this was incompatible disco results. This version has made a change to add node='mix' to channel disco that will enable the queries to be disambiguated. >>> >>> I haven't been able to think of a case other than disco#items on the room >>> JID where MUC and MIX are likely to collide. This change doesn't make it >>> *easy* to implement both on the same domain, but I think it makes it >>> viable >>> - please shout if anyone can think of other cases. >>> >> I agree. Further, I only know of a single client that would ever hit >> disco#items on a room, and that's Psi in its generic disco "browser". >> > Are you suggesting that this approach isn't necessary, and it'd be > sufficient to 'break' disco#items handling for MUC-only clients? > I'd not thought of this approach, but I was considering advocating "just break". I think this means we don't have to. > > /K > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain
On 10/01/2017 14:27, Dave Cridland wrote: On 10 January 2017 at 13:30, Kevin Smith wrote: On 10/01/2017 12:05, Steve Kille wrote: I have just issued a PR for MIX version 0.6.4. There is clear desire to have the option for MUC and MIX to use the same domain.The difficulty in achieving this was incompatible disco results. This version has made a change to add node='mix' to channel disco that will enable the queries to be disambiguated. I haven't been able to think of a case other than disco#items on the room JID where MUC and MIX are likely to collide. This change doesn't make it *easy* to implement both on the same domain, but I think it makes it viable - please shout if anyone can think of other cases. I agree. Further, I only know of a single client that would ever hit disco#items on a room, and that's Psi in its generic disco "browser". Are you suggesting that this approach isn't necessary, and it'd be sufficient to 'break' disco#items handling for MUC-only clients? /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain
On 10 January 2017 at 13:30, Kevin Smith wrote: > On 10/01/2017 12:05, Steve Kille wrote: >> >> I have just issued a PR for MIX version 0.6.4. >> >> There is clear desire to have the option for MUC and MIX to use the same >> domain.The difficulty in achieving this was incompatible disco >> results. >> This version has made a change to >>add node='mix' to channel disco that will enable the queries to be >> disambiguated. > > I haven't been able to think of a case other than disco#items on the room > JID where MUC and MIX are likely to collide. This change doesn't make it > *easy* to implement both on the same domain, but I think it makes it viable > - please shout if anyone can think of other cases. > I agree. Further, I only know of a single client that would ever hit disco#items on a room, and that's Psi in its generic disco "browser". > /K > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain
On 10/01/2017 12:05, Steve Kille wrote: I have just issued a PR for MIX version 0.6.4. There is clear desire to have the option for MUC and MIX to use the same domain.The difficulty in achieving this was incompatible disco results. This version has made a change to add node='mix' to channel disco that will enable the queries to be disambiguated. I haven't been able to think of a case other than disco#items on the room JID where MUC and MIX are likely to collide. This change doesn't make it *easy* to implement both on the same domain, but I think it makes it viable - please shout if anyone can think of other cases. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0369 Proxy JIDs and MIX
There has been quite a bit of discussion on proxy JIDs on the list and there has been some concern on complexity and some consideration of alternatives. Here is a summary of my thinking. 1.The driving requirement for Proxy JIDs is support of JID hidden channels.There was a very strong message from the summit last year that semi-anonymous was vital, particularly because of JID harvesting concerns for public channels. Review of this requirement is on my list of questions for the summit. If JID Hidden Channels (equivalent to MUC semi-anonymous rooms) are not required, proxy JIDs are not needed. 2. While burner JIDs may be helpful to provide a user with complete anonymity in a channel, I think that channel administration needs access to the real JIDs. It would not be acceptable to manage a public MUC and just have a stack of anonymous participants. So use of client provided burner JIDs is not a viable approach to JID hidden channels. 3. Use of MUC style "reference by Nick" (as noted in my message of 6th Jan) is not viable. Kev's response to this set out a several reasons for this.To me, a key issue is "stable identity". Nicks can change, and it is quite possible that different people will use different nicks. This means that when referencing history there will be no clear way for a channel participant to see which individual set what. Addressing this issue was one of the original motivations for MIX. Although there are other reasons, this single reason rules out the approach. My conclusions from this is that we need to have Proxy JIDs in MIX, as I don't anticipate a change of requirements in 1. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain
I have just issued a PR for MIX version 0.6.4. There is clear desire to have the option for MUC and MIX to use the same domain.The difficulty in achieving this was incompatible disco results. This version has made a change to add node='mix' to channel disco that will enable the queries to be disambiguated. Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
