Re: [Standards] Expected behavior when blocking all unknown JIDs
On 11.01.2017 22:05, Evgeny Khramtsov wrote: > Wed, 11 Jan 2017 14:41:51 -0600 > Sam Whited wrote: > >> Currently the blocking command blocks >> *everything* from blocked JIDs; so if you block all JIDs not on your >> roster, you could never receive a subscription request to add them to >> your roster. > > Furthermore, with such blocking you cannot even join a MUC room. Except if you whitelist the relevant MUC domain or the MUC's address prior joining. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Expected behavior when blocking all unknown JIDs
On 11.01.2017 22:13, Daniel Gultsch wrote: > The entire 'block messages from strangers' thing is a poor mans > workaround for the spam problem. I don't think there is a use case for > this outside of fighting spam. And it's not even very effective in > fighting spam as spammers could just move over to subscription spam. It would also block subscription spam. Also I don't see subscription-state based server-side blocking as a primary means against SPAM. How do you counter an attacker with thousands of socket puppet XMPP accounts, registered at hundreds of open services, which constantly send you messages, with and without a body and of different sizes, and presence subscription requests in order to drain your mobile devices battery? The only solution I came up with so far is to give mobile clients the ability to (temporary) block all stanzas from contacts which are not subscribed to their presence. And while privacy lists suck, because they are lists, it is currently the only XEP that does provide such a mechanism. And regarding Sam's UX question: Mobile clients come often in the situation where they could probably change/relaxen the server-side blocking rules, e.g. when charging/AC connected. It is possible to deliver the presence subscription request(s) which where blocked until then when that happens. Happy to discuss and develop an XEP which provides the strengths of privacy lists and blocking commands. I am thinking of an approach which requires the server only to check 3-6 conditions (subscription state, from has domainpart X, from is part of bare address Y, from is in roster group Z, …) on a stanza, with at most one lookup in a set to determine if the condition is meet in order to decide if the stanza should be locked. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Expected behavior when blocking all unknown JIDs
On 11 Jan 2017, at 21:13, Daniel Gultsch wrote: > And yes there are a few users out there for which blocking strangers is an > effective way of fighting spam. However so is blocking messages with Cyrillic > letters in them. This doesn't mean we should make a standard for this. Actually, I’m not convinced this is true. For users who know they don’t expect messages in other scripts, telling the server to block those scripts for them might not be stupid. This is slightly off topic, though. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Expected behavior when blocking all unknown JIDs
On Wed, Jan 11, 2017 at 3:05 PM, Evgeny Khramtsov wrote: > Furthermore, with such blocking you cannot even join a MUC room. I hadn't thought about that case either; thanks. On Wed, Jan 11, 2017 at 3:13 PM, Daniel Gultsch wrote: > I personally couldn't even use it, because blocking messages from strangers > would it turn mean that I would have to allow presence subscription for > random people on the Internet who want to contact me. Ooh yah, I wouldn't want to encourage that model. Thanks; this has already convinced me that it's not worth implementing; I'll pose a new argument for why we should deprecate privacy lists (but not implement this in blocking command before hand) next week. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Expected behavior when blocking all unknown JIDs
The entire 'block messages from strangers' thing is a poor mans workaround for the spam problem. I don't think there is a use case for this outside of fighting spam. And it's not even very effective in fighting spam as spammers could just move over to subscription spam. I personally couldn't even use it, because blocking messages from strangers would it turn mean that I would have to allow presence subscription for random people on the Internet who want to contact me. And yes there are a few users out there for which blocking strangers is an effective way of fighting spam. However so is blocking messages with Cyrillic letters in them. This doesn't mean we should make a standard for this. The spam problem needs to be addressed. But not in this way. And deprecating privacy lists doesn't mean the current implementations will go away. So everybody for whom this is a good enough work around for now can still use it until we come up with something better. On Jan 11, 2017 9:43 PM, "Sam Whited" wrote: > Wed, 11 Jan 2017 14:41:51 -0600 > Sam Whited wrote: > > > Currently the blocking command blocks > > *everything* from blocked JIDs; so if you block all JIDs not on your > > roster, you could never receive a subscription request to add them to > > your roster. > > Furthermore, with such blocking you cannot even join a MUC room. > ___ > 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] Expected behavior when blocking all unknown JIDs
Wed, 11 Jan 2017 14:41:51 -0600 Sam Whited wrote: > Currently the blocking command blocks > *everything* from blocked JIDs; so if you block all JIDs not on your > roster, you could never receive a subscription request to add them to > your roster. Furthermore, with such blocking you cannot even join a MUC room. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Expected behavior when blocking all unknown JIDs
Hi all, There was brief discussion earlier about adding the ability to "block everyone that I don't have in my roster" to XEP-0191: Blocking Command [1]. I was thinking about how this could be done, and it occured to me that it may break the UX a bit. Currently the blocking command blocks *everything* from blocked JIDs; so if you block all JIDs not on your roster, you could never receive a subscription request to add them to your roster. If two accounts both had non-contacts blocked, they'd effectively have to add eachother in parallel; there would be no ability to send a request. We could of course add the ability to block just messages and IQs from contacts not in your roster, but then you could still receive spam via subscription requests with a message. What would people generally expect to happen in this situation? The more I think about it the more I think doing this is effectively an anti-pattern that we shouldn't support (I've never heard of someone blocking everyone who wasn't in their address book from sending them emails), but I wanted to find out what the community thinks. —Sam [1]: https://xmpp.org/extensions/xep-0191.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Obsoleting vCard-Based Avatars
Wed, 11 Jan 2017 19:56:43 + Kevin Smith wrote: > I’m obviously just about the last person to say we shouldn’t be > trying to modernise XMPP, given mix, bind2, etc., but this just > doesn’t seem like an area worth much effort as things stand. What is bind2? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Obsoleting vCard-Based Avatars
On Wed, Jan 11, 2017 at 5:44 PM, Sam Whited wrote: > On Tue, Jan 10, 2017 at 11:04 AM, Kevin Smith > wrote: > > 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. > > In my mind this shouldn't be a consideration; if you don't give people > a compelling reason to upgrade, I don't think they will. Normally this > would be in the form of new features, or something that's easier to > maintain. In this case, however, 0084 doesn't provide anything but > better infrastructure to build on (and no one cares about > infrastructure, it's not shiny enough). Simiarly, some clients not > sending mandatory formats doesn't seem like a reason not to use 0084 > (clients could just as easily send a different format via 0153). > > If we want the ecosystem to move forward, I think the closest thing we > can provide to a compelling reason is to make 0084 the only > recommendation for new implementations (old implementations will fall > into line when they're no longer compatible with any of the shiny new > clients). Right now there are two separate XEPs which serve the same > purpose, and both show up on xmpp.org with green text at the top. The > confusion this causes is, in my opinion, much worse than the > outstanding issues with 0084, and by encouraging implementations of > 0084 by making it the only recommendation we may also encourage > contributions to fix those outstanding issues. > We certainly should have a single standard that covers the UX of sharing an avatar photo, that works in the roster and in group chats, may they be MUC or MIX group chats. If we want XEP-0084 to be that standard, it should ideally cover workaround to make it work in MUC scenarios where it currently does not. A good started would be that the issues are at least discussed in XEP-0084. Clients not using the mandatory image encoding for XEP-0084 definitely is no reason to push for further implementations of it by marking XEP-0153 as Historic. The same clients probably don't use the mandatory image encoding for XEP-0153 either. To further help adoption of XEP-0084, it could be made part of 2017s compliance suites. However, for that it should work in the scenarios where XEP-0153 worked as we certainly don't want to fallback to a worse UX, right? So what are the scenarios in which XEP-0084 doesn't work? What is required to make it work in these scenarios? Is server support required for that (probably)? Will it work flawlessly with MIX? XEP-0084 is based on PEP, which requires knowledge of a bare JID and a presence subscription to that JID. Bare JIDs are not known in anonymous and semi-anonymous MUCs. Another issue is that in semi-anonymous rooms, admins can leak their JID by doing requests to the known full JIDs. MUCs could stamp out local anonymous bare JIDs for this case and present them in the MUC similar to MIX's proxy JID idea. However that's probably quite some work. Does somebody have an idea how to fix this issue in a more lightweight way? Eventually we'll move to MIX in the future I suppose, but that's certainly not going to happen this or next year, at least if you still want to interop with more than a single client. Cheers, Tobi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Obsoleting vCard-Based Avatars
> On 11 Jan 2017, at 16:44, Sam Whited wrote: > > On Tue, Jan 10, 2017 at 11:04 AM, Kevin Smith wrote: >> 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. > > In my mind this shouldn't be a consideration; if you don't give people > a compelling reason to upgrade, I don't think they will. Normally this > would be in the form of new features, or something that's easier to > maintain. In this case, however, 0084 doesn't provide anything but > better infrastructure to build on (and no one cares about > infrastructure, it's not shiny enough). If there isn’t a significant motivation to move from 153 to 84, I’m not sure why we need to push to move from 153 to 84. > Simiarly, some clients not > sending mandatory formats doesn't seem like a reason not to use 0084 > (clients could just as easily send a different format via 0153). Well, saying “Don’t do 153” (with which you’d interop fine), “do 84 instead” (and don’t expect to interop) wouldn’t be a very strong argument, I think :) > If we want the ecosystem to move forward, I think the closest thing we > can provide to a compelling reason is to make 0084 the only > recommendation for new implementations (old implementations will fall > into line when they're no longer compatible with any of the shiny new > clients). Right now there are two separate XEPs which serve the same > purpose, and both show up on xmpp.org with green text at the top. The > confusion this causes is, in my opinion, much worse than the > outstanding issues with 0084, and by encouraging implementations of > 0084 by making it the only recommendation we may also encourage > contributions to fix those outstanding issues. I’m obviously just about the last person to say we shouldn’t be trying to modernise XMPP, given mix, bind2, etc., but this just doesn’t seem like an area worth much effort as things stand. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Obsoleting vCard-Based Avatars
On Tue, Jan 10, 2017 at 11:04 AM, Kevin Smith wrote: > 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. In my mind this shouldn't be a consideration; if you don't give people a compelling reason to upgrade, I don't think they will. Normally this would be in the form of new features, or something that's easier to maintain. In this case, however, 0084 doesn't provide anything but better infrastructure to build on (and no one cares about infrastructure, it's not shiny enough). Simiarly, some clients not sending mandatory formats doesn't seem like a reason not to use 0084 (clients could just as easily send a different format via 0153). If we want the ecosystem to move forward, I think the closest thing we can provide to a compelling reason is to make 0084 the only recommendation for new implementations (old implementations will fall into line when they're no longer compatible with any of the shiny new clients). Right now there are two separate XEPs which serve the same purpose, and both show up on xmpp.org with green text at the top. The confusion this causes is, in my opinion, much worse than the outstanding issues with 0084, and by encouraging implementations of 0084 by making it the only recommendation we may also encourage contributions to fix those outstanding issues. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Meeting 20170111
http://logs.xmpp.org/council/2017-01-11/ 1) Roll Call - http://logs.xmpp.org/council/2017-01-11/#16:01:03 All present. [[ Dave forgot to do the joke about saying "Bacon please!". ]] 2) Minute Taker - http://logs.xmpp.org/council/2017-01-11/#16:03:03 Dave offered, and Tobias foolishly agreed. [[ Really it amazes me that in a community this size, with so many people applying and reapplying for XSF membership every year, we cannot find a minute taker at all this year. If you're reading these minutes, then whether or not you're an XSF member, we'd really appreciate if you offered to take the minutes. Give it a whirl for a meeting, and see if you enjoy it. ]] 3) Move XEP-0153 Obsolete in favour of XEP-0084 - http://logs.xmpp.org/council/2017-01-11/#16:03:56 Dave asked what our precise meaning of Obsolete was in these circumstances. The agreement was that it did simply mean the XEP-0001 definition - that the Council would be recommending no further implementation or deployment. Tobias noted we should explain how XEP-0084 operates with anonymous MUCs, Emmanuel Gil noted that it doesn't work in a number of circumstances including anonymous MUCs, contacts not in the roster, and so on. Sam noted that there is a recurring theme within the community of rejecting any replacement because it does not 100% match the capabilities of the first; Dave noted that in this case there were common use-cases which were missing. Kim noted from the floor that technically speaking, without the special handling MUCs give XEP-0054 requests, XEP-0153 avatars also do not work in MUCs. [[ The discussion was relatively heated, I have attempted to capture the majority of points, but I am of course utterly biased. I recommend that interested readers review the chatroom logs, and, furthermore, volunteer to take minutes! ]] The vote was postponed until next week. 4) XEP-0300 fixing - http://logs.xmpp.org/council/2017-01-11/#16:23:45 See https://github.com/xsf/xeps/issues/349 General agreement that a namespace bump with mandatory base64 encoding is the solution here. Tobias to raise this on the list. 5) Date of Next - http://logs.xmpp.org/council/2017-01-11/#16:26:12 Same time next week. 6) AOB - http://logs.xmpp.org/council/2017-01-11/#16:29:31 None raised. 7) Ite, Meeting Est - http://logs.xmpp.org/council/2017-01-11/#16:31:12 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0033 (Extended Stanza Addressing)
Version 1.2.1 of XEP-0033 (Extended Stanza Addressing) has been released. Abstract: This specification defines an XMPP protocol extension that enables entities to include RFC822-style address headers within XMPP stanzas in order to specify multiple recipients or sub-addresses. Changelog: [See revision history] (cs (XEP Editor: ssw)) Diff: http://xmpp.org/extensions/diff/api/xep/0033/diff/1.2/vs/1.2.1 URL: http://xmpp.org/extensions/xep-0033.html ___ 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.5 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: Modify MIX Proxy so that client sends to bare JID (sek) Diff: http://xmpp.org/extensions/diff/api/xep/0369/diff/0.6.4/vs/0.6.5 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 (MIX) and sorting out co-existence of MUC and MIX on a single domain
On 11 January 2017 at 08:01, Piotr Nosek wrote: > On Tue, Jan 10, 2017 at 3:43 PM, Dave Cridland wrote: >> >> 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. > > > What about using Entity Capabilities to establish whether the client should > receive MIX or MUC stanzas and syntax? I know that it's mandatory for every > client to announce its caps but in such case the server could failover to > default mode. I don't know unfortunately if all major clients include their > version in initial presence... > You don't need to care - a client will either join a MIX using MIX syntax, or else join a MUC using MUC syntax, hosted at the same address. I think that with the disco change Steve has made, the two protocols have no overlap. The outlier case is a client joining a MUC via GC syntax, but I think that's practical too (I just haven't thought much about it). > ___ > 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
What about using Entity Capabilities to establish whether the client should receive MIX or MUC stanzas and syntax? I know that it's mandatory for every client to announce its caps but in such case the server could failover to default mode. I don't know unfortunately if all major clients include their version in initial presence... [Steve Kille] I don’t think this is needed as Presence and Message formats are compatible. MIX messages are sent to the User’s Server (MIX Proxy) and so this keeps things separate anyhow Steve ___ 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 Tue, Jan 10, 2017 at 3:43 PM, Dave Cridland wrote: > 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. What about using Entity Capabilities to establish whether the client should receive MIX or MUC stanzas and syntax? I know that it's mandatory for every client to announce its caps but in such case the server could failover to default mode. I don't know unfortunately if all major clients include their version in initial presence... ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
