Re: [Standards] Deprecating Privacy Lists (again)
btw the Gajim default blocking option should work in 0.16.7 perfectly together with blocking command, just for info. On Topic i think nobody uses Privacy Lists .. like with different lists and setting active this and that and creating cool special rules. At least not in Gajim. Its also very inefficient, i always have to copy whole lists around because it supports no real edits of lists, like adding single items and removing them. We always have to send the whole List. Active Lists not just layering over the default lists is also something i would have expected. It feels like too much stuff is packed into one XEP. For example i find it very good that Invisibility Command will be a own XEP. if i want to go invisible now, i have to add a rule to a list, then send my whole list to the server, or copy the whole list and set another one active. This gets more ugly the more your blocking list grows. So we have Invisibility in a own easy to implement XEP. We have Blocking Command. And if in the future there is one or two use cases that we really want to cover regarding blocking, we can just add it to Blocking Command and we will still be miles away from a Privacy Lists complexity. regards Philipp 2017-03-23 20:14 GMT+01:00 Ruslan N. Marchenko : > > > On 23.03.2017 14:18, Dave Cridland wrote: > >> On 22 March 2017 at 20:08, Ruslan N. Marchenko wrote: >> >>> On 22.03.2017 20:37, Sam Whited wrote: >>> On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger wrote: > One nice feature we also don't have with blocking command is blocking a > while group. > Ah yes! I knew there was something else that I was forgetting to address from last time. I also think this is not a good thing; it is an abuse of roster groups, and leads to an inconsistent experience across clients. It also makes the UX incredibly frustrating. For example: I block a group "work", but then I decide I want to talk to one of my coworkers so I go to their chat, but it says they're blocked. I hit unblock: what happens? >>> >>> It's probably UX problem but not list per se. >>> >> If a protocol explicitly creates UX problems, it's a protocol problem. >> >> List allows you creating overriding allow entry which will unblock single >>> person while keeping the group blocked (order matters). >>> >> There's no way for one client to inform another that this is not a >> general standalone rule, but an explicit exception to a previous rule, >> > But there is, active list. Active list is local to client, default to > user. Active cannot be intermixed with default, so if one client wants an > exception - it may (just a quick guess) copy a list and set it active. > There're plenty of configurations client could apply. Although of course > different implementations will probably treat lists differently. But if > client allows raw list editing - user always has an option to apply > whatever configuration he wants. Gajim is a good example of that - blocking > option + raw editor. > > however. There's no way to say that this exception is a temporary >> case, rather than the norm. There's no way to indicate that this is >> actually a general rule because this particular co-worker is also an >> XSF member, and people in both groups are always unblocked. >> >> I would much rather have clients using a simple interface that covers >> the 90%, than not using a complicated one which fails to cover more >> than 95%. >> > ___ > 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] Deprecating Privacy Lists (again)
On Thu, Mar 23, 2017 at 8:09 AM, Dave Cridland wrote: > I'm in favour of deprecation (but not elimination). I forgot there was a difference, but I used the word I meant purely by accident. To make sure it's absolutely clear: I am advocating that we move XEP-0016 to the "Deprecated" stage described here: [1]. *NOT* to obsolete. —Sam [1]: https://xmpp.org/extensions/xep-0001.html#states-Deprecated ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Deprecating Privacy Lists (again)
On 23.03.2017 14:18, Dave Cridland wrote: On 22 March 2017 at 20:08, Ruslan N. Marchenko wrote: On 22.03.2017 20:37, Sam Whited wrote: On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger wrote: One nice feature we also don't have with blocking command is blocking a while group. Ah yes! I knew there was something else that I was forgetting to address from last time. I also think this is not a good thing; it is an abuse of roster groups, and leads to an inconsistent experience across clients. It also makes the UX incredibly frustrating. For example: I block a group "work", but then I decide I want to talk to one of my coworkers so I go to their chat, but it says they're blocked. I hit unblock: what happens? It's probably UX problem but not list per se. If a protocol explicitly creates UX problems, it's a protocol problem. List allows you creating overriding allow entry which will unblock single person while keeping the group blocked (order matters). There's no way for one client to inform another that this is not a general standalone rule, but an explicit exception to a previous rule, But there is, active list. Active list is local to client, default to user. Active cannot be intermixed with default, so if one client wants an exception - it may (just a quick guess) copy a list and set it active. There're plenty of configurations client could apply. Although of course different implementations will probably treat lists differently. But if client allows raw list editing - user always has an option to apply whatever configuration he wants. Gajim is a good example of that - blocking option + raw editor. however. There's no way to say that this exception is a temporary case, rather than the norm. There's no way to indicate that this is actually a general rule because this particular co-worker is also an XSF member, and people in both groups are always unblocked. I would much rather have clients using a simple interface that covers the 90%, than not using a complicated one which fails to cover more than 95%. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Deprecating Privacy Lists (again)
On 23.03.2017 14:41, Travis Burtrum wrote: Hi all, On 03/22/2017 04:08 PM, Ruslan N. Marchenko wrote: List allows you creating overriding allow entry which will unblock single person while keeping the group blocked (order matters). So does keeping the UI option to block a whole group, and then just Uhm? Group? With XEP-0191? Oh, yes, roster abuse. So UI option to block the group would iterate through all members of the group and put a callback to when the group is updated (roster push), right? using the blocking command to individually block them all. Then Sam's hairy situation of wanting to talk to a single user becomes easy, you just unblock that user. Also this *just works* across all clients. I've yet to see an upside of privacy lists. Thanks, Travis ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0390 (Entity Capabilities 2.0)
Version 0.0.1 of XEP-0390 (Entity Capabilities 2.0) has been released. Abstract: This document overhauls the XMPP protocol extension Entity Capabilities (XEP-0115). It defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities. In order to minimize network impact, the transport mechanism is standard XMPP presence broadcast (thus forestalling the need for polling related to service discovery data), the capabilities information can be cached either within a session or across sessions, and the format has been kept as small as possible. Changelog: First draft. (jwi) Diff: N/A URL: https://xmpp.org/extensions/xep-0390.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Deprecating Privacy Lists (again)
Hi all, On 03/22/2017 04:08 PM, Ruslan N. Marchenko wrote: > List allows you creating overriding allow entry which will unblock > single person while keeping the group blocked (order matters). So does keeping the UI option to block a whole group, and then just using the blocking command to individually block them all. Then Sam's hairy situation of wanting to talk to a single user becomes easy, you just unblock that user. Also this *just works* across all clients. I've yet to see an upside of privacy lists. Thanks, Travis ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23.03.2017 14:31, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 14:25]: >> It is the same feature request for PubSub/PEP. For example when using >> OMEMO you always want to subscribe-and-maybe-create the devicelist node. > > I can see how an UPSERT operation is useful … This is really like an UPSERT, but that is my second feature request where I actually wrote already an ProtoXEP for http://geekplace.eu/xeps/xep-cap/xep-cap.html It is simply CAS for PubSub/PEP, to avoid races when updating nodes. While working on OMEMO, we saw that this may be an useful server feature. Note sure if MIX would benefit form it to (e.g., when updating the channel topic). I'd probably will submit it soon to council. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Software Developers: Action Required
Dear XMPP software authors, The XSF provides a public list of XMPP implementations[0] on its website. For this list to be useful, it should contain up-to-date information about up-to-date software. To achieve this, the XSF Board has decided that all implementations have to reapply once per year, to ensure that they are still actively maintained and that the listed info is accurate. This is a purely formal process, though we encourage implementors to follow the current compliance suites. If you have an entry in one of the lists, please create a pull request as desribed in the README[1] before the 1st of May 2017. There is an example commit[2] that can be used as a reference. Software that is not updated until that date will be automatically removed from the listing. Alternatively, you can ask in the jdev MUC[3] for a manual update of your listing. Please also ensure that you repeat this step in the following years. Thank you for observing all safety precautions. Georg Lukas, on behalf of the XSF Board [0] https://xmpp.org/software [1] https://github.com/xsf/xmpp.org/blob/master/data/README.rst [2] https://github.com/xsf/xmpp.org/commit/8724430ff702bab98865ef2338cd392c277a71ee [3] xmpp:j...@conference.jabber.org?join signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
* Florian Schmaus [2017-03-23 14:25]: > It is the same feature request for PubSub/PEP. For example when using > OMEMO you always want to subscribe-and-maybe-create the devicelist node. I can see how an UPSERT operation is useful on a resource that is exclusively owned by you, but not on a "public asset" shared with other users. > > - Named public long-lived MIXes: you want to either be the owner of it > > or have the creation fail. > You do sometimes have exclusive races against other resources of your JID. Like... when you attempt to create the same channel on two different devices, at the same time? Seriously, there is no such problem with MIX, because the first client creating the MIX will get it pushed into the roster and all the others will be auto-subscribed, or something along these lines. The race condition I see as problematic is different users trying to create the same MIX. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23.03.2017 14:25, Florian Schmaus wrote: > It is the same feature request for PubSub/PEP. For example when using > OMEMO you always want to subscribe-and-maybe-create the devicelist node. > Some goes for the XEP-0080 geoloc node. It would be nice if PubSub would > provide that as primitive. Sorry, not subscribe-and-maybe-create, but retrieve-and-maybe-create. - 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] Join and Create
On 23.03.2017 11:05, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 10:11]: >> That does work if the name of the channel can be random (nameless). But >> I believe that there will be use cases where the name of the channel >> needs to be fixed. > > Yes, there are use cases where a fixed channel name is needed. But do > you really want to end up in a situation where a race condition decides > on who will become the owner of that channel, and where you'll > accidentally expose your full JID to a third party by join-or-creating > some milliseconds too late? See comment below. >> For PubSub/PEP this would be OMEMO, GeoLoc, etc., (although the >> situation here is not so bad, because the nodes don't get deleted usually). > > Sorry, I can't follow you. What's the relevance of the current > discussion to OMEMO etc? It is the same feature request for PubSub/PEP. For example when using OMEMO you always want to subscribe-and-maybe-create the devicelist node. Some goes for the XEP-0080 geoloc node. It would be nice if PubSub would provide that as primitive. >> But yeah, § 6.5.3 could be sufficient in most cases. However, I still >> feel like having an optional atomic join-or-maybe-create operation would >> be nice to have. > > I have a contrary opinion. Join-or-maybe-create is the wrong solution > for the two MIX use cases I see, and it would make implementors take > nasty shortcuts. > > - Named public long-lived MIXes: you want to either be the owner of it > or have the creation fail. You do sometimes have exclusive races against other resources of your JID. - 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] Deprecating Privacy Lists (again)
On 22 March 2017 at 20:08, Ruslan N. Marchenko wrote: > > On 22.03.2017 20:37, Sam Whited wrote: >> >> On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger >> wrote: >>> >>> One nice feature we also don't have with blocking command is blocking a >>> while group. >> >> >> Ah yes! I knew there was something else that I was forgetting to >> address from last time. >> >> I also think this is not a good thing; it is an abuse of roster >> groups, and leads to an inconsistent experience across clients. It >> also makes the UX incredibly frustrating. For example: >> >> I block a group "work", but then I decide I want to talk to one of my >> coworkers so I go to their chat, but it says they're blocked. I hit >> unblock: what happens? > > > It's probably UX problem but not list per se. If a protocol explicitly creates UX problems, it's a protocol problem. > > List allows you creating overriding allow entry which will unblock single > person while keeping the group blocked (order matters). There's no way for one client to inform another that this is not a general standalone rule, but an explicit exception to a previous rule, however. There's no way to say that this exception is a temporary case, rather than the norm. There's no way to indicate that this is actually a general rule because this particular co-worker is also an XSF member, and people in both groups are always unblocked. I would much rather have clients using a simple interface that covers the 90%, than not using a complicated one which fails to cover more than 95%. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Deprecating Privacy Lists (again)
On 22 March 2017 at 19:08, Sam Whited wrote: > I'd love your thoughts before I bring this before the council for a vote. I'm in favour of deprecation (but not elimination). * Privacy lists are mammothly complicated, and therefore error-prone. * While it's possible to implement many complex user desires into a privacy list, it is not possible to do so such that another client will understand the desires. More comments against individual responses... Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
On Mittwoch, 22. März 2017 18:48:06 CET edhe...@movim.eu wrote: > * var='Participation Addition by Invitation from Participant' > > * I think that it would be better to set this field var to > 'participation_addition_by_invitation_from_participant' and use the > label tag for all the jabber:x:data fields for a proper labeling system. > > * This will simplify the mapping of the fields and prevent > uppercase/lowercase/spaces issues in the servers and clients > implementations The use of entirely human-readable variable names in the configuration node slipped my first reading. To double check I’ve skimmed XEP-0004 and XEP-0068 and names with spaces are not in violation with any of those. Nevertheless, I personally don’t like that, but that’s just like, my opinion, man. regards, jwi signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
* Florian Schmaus [2017-03-23 10:11]: > That does work if the name of the channel can be random (nameless). But > I believe that there will be use cases where the name of the channel > needs to be fixed. Yes, there are use cases where a fixed channel name is needed. But do you really want to end up in a situation where a race condition decides on who will become the owner of that channel, and where you'll accidentally expose your full JID to a third party by join-or-creating some milliseconds too late? > For PubSub/PEP this would be OMEMO, GeoLoc, etc., (although the > situation here is not so bad, because the nodes don't get deleted usually). Sorry, I can't follow you. What's the relevance of the current discussion to OMEMO etc? > But yeah, § 6.5.3 could be sufficient in most cases. However, I still > feel like having an optional atomic join-or-maybe-create operation would > be nice to have. I have a contrary opinion. Join-or-maybe-create is the wrong solution for the two MIX use cases I see, and it would make implementors take nasty shortcuts. - Named public long-lived MIXes: you want to either be the owner of it or have the creation fail. - Anon/private MIXes: just use §6.5.3 Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23.03.2017 09:38, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 08:22]: >> Consider an chess-game service build on top of MIX. Tim and Tom want to >> play a game and agree on the "TimAndTomsGame" as name. Now both clients >> want to join-and-maybe-create the TimAndTomsGame MIX channel. > > I think this is exactly what §6.5.3 "Creating a Channel for Ad Hoc Use" > is meant for. One of the two creates such a "nameless" channel and sends > an invitation, there is really no need to have both parties trying to > create it, or any kind of out-of-band name arbitration. That does work if the name of the channel can be random (nameless). But I believe that there will be use cases where the name of the channel needs to be fixed. For PubSub/PEP this would be OMEMO, GeoLoc, etc., (although the situation here is not so bad, because the nodes don't get deleted usually). But yeah, § 6.5.3 could be sufficient in most cases. However, I still feel like having an optional atomic join-or-maybe-create operation would be nice to have. - 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] Join and Create
On 23 March 2017 at 08:38, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 08:22]: >> Consider an chess-game service build on top of MIX. Tim and Tom want to >> play a game and agree on the "TimAndTomsGame" as name. Now both clients >> want to join-and-maybe-create the TimAndTomsGame MIX channel. > > I think this is exactly what §6.5.3 "Creating a Channel for Ad Hoc Use" > is meant for. One of the two creates such a "nameless" channel and sends > an invitation, there is really no need to have both parties trying to > create it, or any kind of out-of-band name arbitration. > > Just because in MUC there was no explicit way to create such a private > channel, we don't need to mimic the old behavior in MIX. > > I'm not convinced by this example, and I think there is no other > compelling use case for that functionality. +1. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
* Florian Schmaus [2017-03-23 08:22]: > Consider an chess-game service build on top of MIX. Tim and Tom want to > play a game and agree on the "TimAndTomsGame" as name. Now both clients > want to join-and-maybe-create the TimAndTomsGame MIX channel. I think this is exactly what §6.5.3 "Creating a Channel for Ad Hoc Use" is meant for. One of the two creates such a "nameless" channel and sends an invitation, there is really no need to have both parties trying to create it, or any kind of out-of-band name arbitration. Just because in MUC there was no explicit way to create such a private channel, we don't need to mimic the old behavior in MIX. I'm not convinced by this example, and I think there is no other compelling use case for that functionality. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
Flo, I'm not convinced by this example. MIX is primarily oriented for end users, not as a building block like PubSub. I don't see this example as a target application and the issue seems quite pathological to me Steve > > Couldn't this be a create followed by a join? > > If the channel already exists, then the create would return an error > > (which you can ignore). > > That is basically what Smack does [1], as I've written in [2], but is not > sufficient. > > A simple example: > > Consider an chess-game service build on top of MIX. Tim and Tom want to > play a game and agree on the "TimAndTomsGame" as name. Now both > clients want to join-and-maybe-create the TimAndTomsGame MIX channel. > > Currently a client implementation will look something like this (note that it > does matter if you try to create first and then join, or the other way around): > > result = join(TimAndTomsGame) > if (result == channel-does-not-exist) { >// A >result = create(TimAndTomsGame) >if (result = channel-does-exist) { > // B > result = join(TimAndTomsGame) >} > } > > This tries to fix all the races, but fails. A is what you mentioned. But if Tom > decides that he has waited long enough while Tim is at B, and leaves the > channel, upon which the channel will get auto-destroyed, then Tim will get a > channel-does-not-exist result using this logic. > > The only way to solve this is to make this an atomic operation at protocol > level. Which is trivial to add, simply define an IQ which has "two" child > elements, and , and easy to implement server side (and, of > course, client side). > > - Florian > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23.03.2017 04:14, Daurnimator wrote: > On 23 March 2017 at 01:40, Florian Schmaus wrote: >> On 22.03.2017 12:53, Steve Kille wrote: >>> I think that keeping Create and Join separate is the right thing. >> >> They can and should be separate, but I think there needs to be a third >> operation "join-and-maybe-create". Otherwise the protocol is incomplete >> and broken. >> >>> I feel that we have enough complexity with the modular operations, without >>> creating compound operations that will have whole new classes of error to >>> consider >> >> How about making this an optional feature in an add-on XEP? > > Couldn't this be a create followed by a join? > If the channel already exists, then the create would return an error > (which you can ignore). That is basically what Smack does [1], as I've written in [2], but is not sufficient. A simple example: Consider an chess-game service build on top of MIX. Tim and Tom want to play a game and agree on the "TimAndTomsGame" as name. Now both clients want to join-and-maybe-create the TimAndTomsGame MIX channel. Currently a client implementation will look something like this (note that it does matter if you try to create first and then join, or the other way around): result = join(TimAndTomsGame) if (result == channel-does-not-exist) { // A result = create(TimAndTomsGame) if (result = channel-does-exist) { // B result = join(TimAndTomsGame) } } This tries to fix all the races, but fails. A is what you mentioned. But if Tom decides that he has waited long enough while Tim is at B, and leaves the channel, upon which the channel will get auto-destroyed, then Tim will get a channel-does-not-exist result using this logic. The only way to solve this is to make this an atomic operation at protocol level. Which is trivial to add, simply define an IQ which has "two" child elements, and , and easy to implement server side (and, of course, client side). - Florian 1: https://github.com/igniterealtime/Smack/blob/08c228ef99b59c7c16b44941875e1ea640db3b62/smack-extensions/src/main/java/org/jivesoftware/smackx/pubsub/PubSubManager.java#L272 1: https://mail.jabber.org/pipermail/standards/2017-March/032419.html signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___