Re: [Standards] invisibility
On 5/29/12 10:16 AM, Goffi wrote: It seems that it's not possible to be visible to only a roster group with XEP-0186 (except by sending directed presence to each jid individually). For me it's an important point do manage visibility at the roster group level, this is possible with privacy lists, not with XEP-0186. Hi Goffi, I was thinking about this further, and as you say it *is* possible to manage visibility at the roster level with XEP-0186: you just need to send directed presence to everyone in a particular group if you want to appear online to them. I realize that's not as clean from a protocol perspective, but the protocol details can be hidden from the end user anyway (something like right-clicking appear visible to this group in the roster list can trigger some number of directed presence stanzas). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
On 29 May 2012 16:35, Peter Saint-Andre stpe...@stpeter.im wrote: I'm not a big fan of invisibility, but if we're going to do it then we might as well do it right. Some clients and servers use XEP-0018, but it violates the core XMPP specs, which seems like a bad idea. Some clients and server use privacy lists (XEP-0016 + XEP-0126), but they're complicated and I'd prefer to deprecate them if possible (that's really a separate discussion topic). Years ago I defined a better solution in XEP-0186, but we never pushed it forward from Experimental to Draft. I don't know if any clients and servers include support for XEP-0186, but if so it would be good to know. In any case, I'm wondering if folks are interested in seeing XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. I'm 200% in favour of this. We don't yet have a plugin for Prosody, but it would be pretty trivial to do. I recently learnt that Telepathy/Empathy implements it, so we already have a client in the wild to test against. Regards, Matthew
Re: [Standards] invisibility
On Tue, May 29, 2012 at 4:35 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I'm not a big fan of invisibility, but if we're going to do it then we might as well do it right. Some clients and servers use XEP-0018, but it violates the core XMPP specs, which seems like a bad idea. Some clients and server use privacy lists (XEP-0016 + XEP-0126), but they're complicated and I'd prefer to deprecate them if possible (that's really a separate discussion topic). Years ago I defined a better solution in XEP-0186, but we never pushed it forward from Experimental to Draft. I don't know if any clients and servers include support for XEP-0186, but if so it would be good to know. In any case, I'm wondering if folks are interested in seeing XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. I think 186 is the least offensive way to do invisibility that we have, although it does have bits of ick in there (MUST enforce UI behaviour). /K
Re: [Standards] invisibility
On May 29, 2012, at 09:35, Peter Saint-Andre wrote: I'm not a big fan of invisibility, but if we're going to do it then we might as well do it right. Some clients and servers use XEP-0018, but it violates the core XMPP specs, which seems like a bad idea. Some clients and server use privacy lists (XEP-0016 + XEP-0126), but they're complicated and I'd prefer to deprecate them if possible (that's really a separate discussion topic). Years ago I defined a better solution in XEP-0186, but we never pushed it forward from Experimental to Draft. I don't know if any clients and servers include support for XEP-0186, but if so it would be good to know. In any case, I'm wondering if folks are interested in seeing XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? Simpler invisibility would be very nice. - mm Matthew A. Miller http://goo.gl/LK55L smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Standards] invisibility
On Tue, May 29, 2012 at 5:03 PM, Matthew Miller linuxw...@outer-planes.net wrote: On May 29, 2012, at 09:35, Peter Saint-Andre wrote: I'm not a big fan of invisibility, but if we're going to do it then we might as well do it right. Some clients and servers use XEP-0018, but it violates the core XMPP specs, which seems like a bad idea. Some clients and server use privacy lists (XEP-0016 + XEP-0126), but they're complicated and I'd prefer to deprecate them if possible (that's really a separate discussion topic). Years ago I defined a better solution in XEP-0186, but we never pushed it forward from Experimental to Draft. I don't know if any clients and servers include support for XEP-0186, but if so it would be good to know. In any case, I'm wondering if folks are interested in seeing XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? Simpler invisibility would be very nice. How would one make it simpler? 186 is already just one stanza. /K
Re: [Standards] invisibility
On May 29, 2012, at 10:04, Kevin Smith wrote: On Tue, May 29, 2012 at 5:03 PM, Matthew Miller linuxw...@outer-planes.net wrote: On May 29, 2012, at 09:35, Peter Saint-Andre wrote: I'm not a big fan of invisibility, but if we're going to do it then we might as well do it right. Some clients and servers use XEP-0018, but it violates the core XMPP specs, which seems like a bad idea. Some clients and server use privacy lists (XEP-0016 + XEP-0126), but they're complicated and I'd prefer to deprecate them if possible (that's really a separate discussion topic). Years ago I defined a better solution in XEP-0186, but we never pushed it forward from Experimental to Draft. I don't know if any clients and servers include support for XEP-0186, but if so it would be good to know. In any case, I'm wondering if folks are interested in seeing XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? Simpler invisibility would be very nice. How would one make it simpler? 186 is already just one stanza. Let's say Having a non-experimental protocol for invisibility would be very nice. d-: - mm Matthew A. Miller http://goo.gl/LK55L smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Standards] invisibility
XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-)
Re: [Standards] invisibility
On Tue, May 29, 2012 at 5:12 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) Right, that's motivated by avoiding the presence leak - but as servers could be probing for presence regardless of the respective user being online, probably this isn't a necessary restriction (and it's obviously harmful to user experience). I think I've argued for its inclusion in the past; I'm more mellow now. /K
Re: [Standards] invisibility
G'day, It seems that it's not possible to be visible to only a roster group with XEP-0186 (except by sending directed presence to each jid individually). For me it's an important point do manage visibility at the roster group level, this is possible with privacy lists, not with XEP-0186. Cheers Goffi Le mardi 29 mai 2012 09:35:10 Peter Saint-Andre a écrit : I'm not a big fan of invisibility, but if we're going to do it then we might as well do it right. Some clients and servers use XEP-0018, but it violates the core XMPP specs, which seems like a bad idea. Some clients and server use privacy lists (XEP-0016 + XEP-0126), but they're complicated and I'd prefer to deprecate them if possible (that's really a separate discussion topic). Years ago I defined a better solution in XEP-0186, but we never pushed it forward from Experimental to Draft. I don't know if any clients and servers include support for XEP-0186, but if so it would be good to know. In any case, I'm wondering if folks are interested in seeing XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? Peter
Re: [Standards] invisibility
On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) I've mentioned before here that this is one of the few changes I would like to make to the XEP - add an attribute such as probe='true' to allow the client to ask the server to probe contacts (with the consequence of not necessarily being so invisible any more). Regards, Matthew
Re: [Standards] invisibility
On 5/29/12 10:02 AM, Kevin Smith wrote: On Tue, May 29, 2012 at 4:35 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I'm not a big fan of invisibility, but if we're going to do it then we might as well do it right. Some clients and servers use XEP-0018, but it violates the core XMPP specs, which seems like a bad idea. Some clients and server use privacy lists (XEP-0016 + XEP-0126), but they're complicated and I'd prefer to deprecate them if possible (that's really a separate discussion topic). Years ago I defined a better solution in XEP-0186, but we never pushed it forward from Experimental to Draft. I don't know if any clients and servers include support for XEP-0186, but if so it would be good to know. In any case, I'm wondering if folks are interested in seeing XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. I think 186 is the least offensive way to do invisibility that we have, although it does have bits of ick in there (MUST enforce UI behaviour). I'm happy to revisit and remove the ick. I looked at it again this morning for the first time in a few years, and I noticed that it needs to be updated in several respects (it still references RFC 3921 etc.). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
On 5/29/12 10:36 AM, Matthew Wild wrote: On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) Perhaps that is my diabolical plan! ;-) I've mentioned before here that this is one of the few changes I would like to make to the XEP - add an attribute such as probe='true' to allow the client to ask the server to probe contacts (with the consequence of not necessarily being so invisible any more). That slightly complicates this ultra-simple extension. Since the 'probe' attribute would default to FALSE, I'd be fine with adding this feature (as long as people understand the implications). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
On 5/29/12 10:16 AM, Goffi wrote: G'day, It seems that it's not possible to be visible to only a roster group with XEP-0186 (except by sending directed presence to each jid individually). For me it's an important point do manage visibility at the roster group level, this is possible with privacy lists, not with XEP-0186. So it sounds as if you're a target user for privacy lists. :) I'm not necessarily interested in forbidding or deprecating privacy lists, but in general I think they're complicated and that invisiblity and blocking are the most common use cases, and that *most* people can be served by XEP-0186 for invisibility and XEP-0191 for blocking. At least, that is my working hypothesis. Peter
Re: [Standards] invisibility
On 29 May 2012 17:53, Peter Saint-Andre stpe...@stpeter.im wrote: On 5/29/12 10:36 AM, Matthew Wild wrote: On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) Perhaps that is my diabolical plan! ;-) I've mentioned before here that this is one of the few changes I would like to make to the XEP - add an attribute such as probe='true' to allow the client to ask the server to probe contacts (with the consequence of not necessarily being so invisible any more). That slightly complicates this ultra-simple extension. Since the 'probe' attribute would default to FALSE, I'd be fine with adding this feature (as long as people understand the implications). Given that it is currently ultra-simple I'm happy to bump it up to plain 'simple' with the addition of an optional attribute. Philipp is right about not sending probes being problematic... other IM networks do not show all contacts offline when you are invisible, it's quite user-unfriendly to do that. Still, it does have privacy issues - and thus I'm happy to push the choice to client developers (they can either make the choice for their users, or push the choice to users through a one-time prompt or such). I don't think this is the kind of choice that should be made by protocol designers, sometimes users are willing to risk theoretical presence leaks just to avoid their boss seeing them online on a Saturday :) Regards, Matthew
Re: [Standards] invisibility
On May 29, 2012, at 10:53, Peter Saint-Andre wrote: On 5/29/12 10:36 AM, Matthew Wild wrote: On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) Perhaps that is my diabolical plan! ;-) I've mentioned before here that this is one of the few changes I would like to make to the XEP - add an attribute such as probe='true' to allow the client to ask the server to probe contacts (with the consequence of not necessarily being so invisible any more). That slightly complicates this ultra-simple extension. Since the 'probe' attribute would default to FALSE, I'd be fine with adding this feature (as long as people understand the implications). RFC 6121 specifies probes be sent 'from' a bare JID 'to' a bare JID. I think this limits the presence leak severely, but that's my interpretation (-: - mm Matthew A. Miller http://goo.gl/LK55L smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Standards] invisibility
On Tue, May 29, 2012 at 6:02 PM, Matthew Wild mwi...@gmail.com wrote: On 29 May 2012 17:53, Peter Saint-Andre stpe...@stpeter.im wrote: On 5/29/12 10:36 AM, Matthew Wild wrote: On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) Perhaps that is my diabolical plan! ;-) I've mentioned before here that this is one of the few changes I would like to make to the XEP - add an attribute such as probe='true' to allow the client to ask the server to probe contacts (with the consequence of not necessarily being so invisible any more). That slightly complicates this ultra-simple extension. Since the 'probe' attribute would default to FALSE, I'd be fine with adding this feature (as long as people understand the implications). Given that it is currently ultra-simple I'm happy to bump it up to plain 'simple' with the addition of an optional attribute. Philipp is right about not sending probes being problematic... other IM networks do not show all contacts offline when you are invisible, it's quite user-unfriendly to do that. Still, it does have privacy issues - and thus I'm happy to push the choice to client developers (they can either make the choice for their users, or push the choice to users through a one-time prompt or such). I don't think this is the kind of choice that should be made by protocol designers, sometimes users are willing to risk theoretical presence leaks just to avoid their boss seeing them online on a Saturday :) We already have invisibility that works if you're happy with not seeing contacts' presence - not sending your own :) /K
Re: [Standards] invisibility
On 29 May 2012 18:03, Matthew Miller linuxw...@outer-planes.net wrote: On May 29, 2012, at 10:53, Peter Saint-Andre wrote: On 5/29/12 10:36 AM, Matthew Wild wrote: On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) Perhaps that is my diabolical plan! ;-) I've mentioned before here that this is one of the few changes I would like to make to the XEP - add an attribute such as probe='true' to allow the client to ask the server to probe contacts (with the consequence of not necessarily being so invisible any more). That slightly complicates this ultra-simple extension. Since the 'probe' attribute would default to FALSE, I'd be fine with adding this feature (as long as people understand the implications). RFC 6121 specifies probes be sent 'from' a bare JID 'to' a bare JID. I think this limits the presence leak severely, but that's my interpretation (-: It's only a matter of time before someone in the Prosody community writes a module that fakes available presence for users it receives a probe from :) Regards, Matthew PS. and it'll only be a short time after that that a module is written to automatically send probes randomly while the user is offline...
Re: [Standards] invisibility
On 5/29/12 10:12 AM, Philipp Hancke wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) Hi Philipp, I looked at XEP-0186 again and it doesn't say that. It does say that if there is only one connected resource (i.e., the invisible one) then the server must respond to inbound presence probes as if the user were offline. But the spec doesn't say anything about outbound presence probes. Unless I'm missing something. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
On Tue, May 29, 2012 at 6:09 PM, Matthew Wild mwi...@gmail.com wrote: On 29 May 2012 18:03, Matthew Miller linuxw...@outer-planes.net wrote: On May 29, 2012, at 10:53, Peter Saint-Andre wrote: On 5/29/12 10:36 AM, Matthew Wild wrote: On 29 May 2012 17:12, Philipp Hancke fi...@goodadvice.pages.de wrote: XEP-0186 move to Draft so that we can deprecate XEP-0018 and XEP-0126. Thoughts? I'd note that in 3.1.1. the server MUST NOT send presence probes when being the client is in invisible mode. Of course that makes invisibility much less useful ;-) Perhaps that is my diabolical plan! ;-) I've mentioned before here that this is one of the few changes I would like to make to the XEP - add an attribute such as probe='true' to allow the client to ask the server to probe contacts (with the consequence of not necessarily being so invisible any more). That slightly complicates this ultra-simple extension. Since the 'probe' attribute would default to FALSE, I'd be fine with adding this feature (as long as people understand the implications). RFC 6121 specifies probes be sent 'from' a bare JID 'to' a bare JID. I think this limits the presence leak severely, but that's my interpretation (-: It's only a matter of time before someone in the Prosody community writes a module that fakes available presence for users it receives a probe from :) This is true - but they might get surprising results, even on the network as it already is. /K
Re: [Standards] invisibility
Am 29.05.2012 19:03, schrieb Matthew Miller: RFC 6121 specifies probes be sent 'from' a bare JID 'to' a bare JID. I think this limits the presence leak severely, but that's my interpretation (-: Well, yes. Unfortunately, my server has a much higher interest in keeping me informed about who is interested in my presence than in helping you to stalk me. There is currently no xmppish way for my server to convey this information to my client though. Maybe that's the reason why google is getting away with that leak in gmail... :-)
Re: [Standards] invisibility
On Tuesday, May 29, 2012 10:09:27 AM Matthew Wild wrote: PS. and it'll only be a short time after that that a module is written to automatically send probes randomly while the user is offline... +1 for faster logins
Re: [Standards] invisibility
On 29 May 2012 18:57, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: On Tuesday, May 29, 2012 10:09:27 AM Matthew Wild wrote: PS. and it'll only be a short time after that that a module is written to automatically send probes randomly while the user is offline... +1 for faster logins Random probes aren't necessarily needed for that. We already have a module for caching contact presence and sending that to clients on login before probes are responded to. Regards, Matthew
Re: [Standards] invisibility
Am 29.05.2012 20:04, schrieb Matthew Wild: On 29 May 2012 18:57, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: On Tuesday, May 29, 2012 10:09:27 AM Matthew Wild wrote: PS. and it'll only be a short time after that that a module is written to automatically send probes randomly while the user is offline... +1 for faster logins Random probes aren't necessarily needed for that. We already have a module for caching contact presence and sending that to clients on login before probes are responded to. Does that module allow you to get rid of people who seem (cached) to be available but are not? Expiring cached presence seems so SIMPLE...
Re: [Standards] invisibility
On Tuesday, May 29, 2012 11:04:46 AM Matthew Wild wrote: On 29 May 2012 18:57, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: On Tuesday, May 29, 2012 10:09:27 AM Matthew Wild wrote: PS. and it'll only be a short time after that that a module is written to automatically send probes randomly while the user is offline... +1 for faster logins Random probes aren't necessarily needed for that. We already have a module for caching contact presence and sending that to clients on login before probes are responded to. Good point. Collecting incoming presence sent voluntarily by contacts is generally good enough once you've done an initial probe. After all, that's how traditional clients and servers behave for the duration of a client session. Sounds like Prosody is already very close to being able to have an invisibility feature with no presence leaking. Justin
Re: [Standards] invisibility
Le 29/05/2012 19:01, Peter Saint-Andre a écrit : So it sounds as if you're a target user for privacy lists. :) I'm not necessarily interested in forbidding or deprecating privacy lists, but in general I think they're complicated and that invisiblity and blocking are the most common use cases, and that *most* people can be served by XEP-0186 for invisibility and XEP-0191 for blocking. At least, that is my working hypothesis. Peter I'm OK for simplifying invisibility, as long as privacy lists are not deprecated: they are really useful IMHO. Generally speaking, I'm working a lot, and will work a lot in the future with roster groups.
Re: [Standards] invisibility
On 5/29/12 4:31 PM, Goffi wrote: Le 29/05/2012 19:01, Peter Saint-Andre a écrit : So it sounds as if you're a target user for privacy lists. :) I'm not necessarily interested in forbidding or deprecating privacy lists, but in general I think they're complicated and that invisiblity and blocking are the most common use cases, and that *most* people can be served by XEP-0186 for invisibility and XEP-0191 for blocking. At least, that is my working hypothesis. Peter I'm OK for simplifying invisibility, as long as privacy lists are not deprecated: they are really useful IMHO. Yes, that is the approach I foresee. One of the challenges for server implementers is keeping their privacy-lists datastore in sync with changes caused by client use of the invisibility command (XEP-0186) or the blocking command (XEP-0191). But that might be more of an implementation detail than something we need to specify deeply in the protocol specs. Generally speaking, I'm working a lot, and will work a lot in the future with roster groups. Good to know. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
On Wed, Oct 8, 2008 at 12:20 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Fabio Forno wrote: (sorry for the delays, but in the last two days of many standards_ml mails went into the spam folder :( ) Hopefully I just put an end to that! I think the problem comes mainly from the google talk ml, which is full of spam, and it makes the bayesian filter learn that xmpp or jabber may be related to spam :( So this is interesting. In the resource generation thread, we have people trying to fix something that's not broken. In this thread, we have people trying to prevent anyone from fixing something that *is* broken. Human psychology is endlessly fascinating. :) The power of diversity ;) Privacy lists were unnecessary even in the very beginning to solve the problem we thought they needed to solve, which is essentially the following points from RFC 2779: [...] Given that so many developers find privacy lists so confusing (not to mention end users!!!), I would very much like to use XEP-0191 and XEP-0186 for blocking and invisibility because they are much simpler for everyone to grok (block this user, go invisible, what could be easier?). If people then feel they need privacy lists for some more advanced functionality, we have the technology ready to use. But I see no good reason to keep hitting these two particular nails with the big sledgehammer we created back in 2002 (does anyone here remember zebra lists?) when much simpler tools can do the job. I get the point, but what will happen by adopting the simple solutions? A possible scenario: - for invisibility and blocking the simple xeps are used - privacy lists will stay (at list I hope, since they are the only way to do things like temporary going online for only a subset of users, which is critical on mobiles with rosters getting bigger a bigger and consequent flood of presence) - use of privacy lists will remain inconsistent between clients since they will be used only in the border case explained above, with the risk of setting a list in a session and messing up everything when changing client - developers even more confused of what to use and when, also because if the hammer is still there without safety instructions somebody will be tempted to use it instead of the simple solutions (as we where saying we are all different, and somebody may think why use the limited rules when I have a much powerful tool?: the dark side of force is powerful! ;) ) Ok, we can't stop people from doing stupid things, but at least we should warn by updating xep-16 better clarifying when to use it. Imho this Note: The protocol specified herein MAY be used in conjunction with Simple Communications Blocking [1]; see XEP-0191 for details. is not enough strong, but I'd say that they shouldn't be used in the cases covered by the simple xeps (I think MUST can't be used because it is impossible to enforce it) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] invisibility
Jonathan Schleifer wrote: Many argue that privacy lists are too complex for invisibility or blocking users. For example, the Pidgin developers. They complained that they need to implement privacy lists completely in order to achieve invisibility and blocking. IMO, we could change the XEP to include some reserved names for priacy lists like blocked or invisible, so that all clients can use them together without any problems. Just setting enabling a privacy thing is easy, the problem is interferences with other clients. This would be solved if we had some reserverd names for privacy lists. And how would be be invisible AND block some users (to not receive SPIM)? -- Yann
Re: [Standards] invisibility
Easy: use XEP-0186 to go invisible and XEP-0191 to block users. : He was making a point against throwing away those XEPs and replacing them with privacy lists. cheers, Remko
Re: [Standards] invisibility
On Oct 06, 2008, at 18:08, Jonathan Schleifer wrote: Yes, I agree, privacy lists give us all we need for invisibility. Some might see this as abusing privacy lists, but IMO, that's what they are for. They are to block presence or messages to specific users and/or groups. And all users could also be seen as a group. What I personally like about privacy lists: I can have my own invisibility mode, which means I'm invisible to all except a few persons. I can also have more than one invisiblility mode: For example one that just hides me from groups that are often annoying. Ideally, the client would have a sub-menu invisible where I can define my own invisible modes via privacy lists. There's only one thing I'm missing in privacy lists: Time-based privacy lists. So you can say I want to be invisible to group A, B, C etc. from 8pm to 8am. This would be for example useful if you don't want to get annoyed by your co-workers in the evening. The server would then automatically enable the privacy list if you selected a time for it. I'm sorry to say, but you're not the target audience for 90% of the XMPP clients. I'd get laughed out of the #adium channel if I'd propose a user interface that would be required for a privacy list generator that would be able to generate the lists you described. In addition, if you don't want to wipe the user's privacy lists that are already there, you also need a semantic analyzation of them, which is probably worth writing a paper on artificial intelligence on that topic. If I just let the user do that, I'd have to ask the user to learn programming to manage the interface. In addition to that, if two instances of my client, or another client implementing privacy lists, connect to the same account, all bets are off. Anything could happen. The privacy lists are very potent, but their complexity is just too much for mere mortals. andy
Re: [Standards] invisibility
On Mon, 6 Oct 2008 17:02:24 +0100 Artur Hefczyc [EMAIL PROTECTED] wrote: Hi, While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? The implication is that the user's information about the presence of its contacts will soon become stale. But I suppose that's one price you pay for invisibility, which I continue to think is a stupid concept anyway. :) I thought we gave up with invisibility anyway. Especially that this can be quite easily achieved with privacy lists without those unwanted side effects. And privacy lists give us much more flexibility to set invisibility for a single user, group. I'm afraid you missed one thing. These unwanted side effects can't be avoided. Therefore privacy lists have them too, of course. Pavel Artur -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] invisibility
Pavel Simerda wrote: On Mon, 6 Oct 2008 17:02:24 +0100 Artur Hefczyc [EMAIL PROTECTED] wrote: Hi, While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? The implication is that the user's information about the presence of its contacts will soon become stale. But I suppose that's one price you pay for invisibility, which I continue to think is a stupid concept anyway. :) I thought we gave up with invisibility anyway. Especially that this can be quite easily achieved with privacy lists without those unwanted side effects. And privacy lists give us much more flexibility to set invisibility for a single user, group. I'm afraid you missed one thing. These unwanted side effects can't be avoided. Therefore privacy lists have them too, of course. Right. As far as I can see, there is no way to avoid unwanted side effects with invisibility (no matter whether it is implemented via XEP-0018, XEP-0126, or XEP-0186). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
Pedro Melo wrote: When I move to invisible, I don't want people to know that I'm invisible, so if someone in my rosters asks for last activity, the response should be consistent with my make-believe offline mode: the last-activity is the time of my logout. Right. Giving a radically different response when you move from visible to invisible is a clear signature of invisibility. For invisibility to work sort-of-correctly, we need to look at its impact on anything presence-related: last activity, error handling, and other things. I'll try to do that soon for XEP-0186 (the analysis would apply to any invisibility protocol). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
Imho this is not a protocol issue, but a client issue This has been discussed in length before, and the conclusion was that there is no user friendly *and* correct way to do invisibility on top of privacy lists, or any kind of simple operation (such as blocking). Psi has a 'simple' user interface for blocking contacts on top of privacy lists, but if you used *any* other client to do some privacy list operation, then it could break this. We show a warning 'your list may not work', but this is just a horrible user experience. And things get even nastier if you do invisibility, with all kinds of problematic corner cases. Maybe you should look up the original discussion. You cannot fully abstract something that is fundamentally complex. Sooner or later, a user of your abstraction will bump into a problem, and will not understand it unless he understands the concepts underlying your abstraction. cheers, Remko
Re: [Standards] invisibility
Hi, On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 16:50:54 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote: While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? Depends. It defeats the purpose of lurkers, who want to keep seeing the others online without revealing their own presence. But if you want to be online to talk to XMPP-based services but skip Instant Messaging, I think its ok. I assume that if you are really interested on getting presence updates from a particular contact, you would send him a directed presence and become visible just for him. Anyway, in a federated network, I don't see a way to do better than this. If we had a server-2-server protocol for hey, i'm invisible but keep sending those presences, you would be leaking the presence anyway. I'm fine with this XEP as it stands. One nit: third security consideration, about last activity - replying service-unavailable / is a information leak. The proper reply would be to reply with the time of invisible request. This would also leak information :). If you don't want others to know you are online... you might also not want them to know you connected just five minutes ago. Huhs? Sorry, don't follow. last-activity will only reply to people already on your roster. When I move to invisible, I don't want people to know that I'm invisible, so if someone in my rosters asks for last activity, the response should be consistent with my make-believe offline mode: the last-activity is the time of my logout. Giving a radically different response when you move from visible to invisible is a clear signature of invisibility. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] invisibility
On Tue, Oct 7, 2008 at 10:43 AM, Andreas Monitzer [EMAIL PROTECTED] wrote: The privacy lists are very potent, but their complexity is just too much for mere mortals. Imho this is not a protocol issue, but a client issue: the interface should be designed better for hiding the complexity of privacy lists to mere mortals. I'd stay with the privacy list approach and discuss better ways for setting them. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] invisibility
Remko Tronçon wrote: Imho this is not a protocol issue, but a client issue This has been discussed in length before, and the conclusion was that there is no user friendly *and* correct way to do invisibility on top of privacy lists, or any kind of simple operation (such as blocking). Psi has a 'simple' user interface for blocking contacts on top of privacy lists, but if you used *any* other client to do some privacy list operation, then it could break this. We show a warning 'your list may not work', but this is just a horrible user experience. And things get even nastier if you do invisibility, with all kinds of problematic corner cases. Maybe you should look up the original discussion. You cannot fully abstract something that is fundamentally complex. Sooner or later, a user of your abstraction will bump into a problem, and will not understand it unless he understands the concepts underlying your abstraction. I agree, which is why I've been pushing for: 1. Simple blocking (XEP-0191). 90% of the time all you want to do is block some luser, not use the full power of privacy lists. 2. Simple invisibility (XEP-0186). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
On Tue, 7 Oct 2008 14:50:35 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 16:50:54 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote: While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? Depends. It defeats the purpose of lurkers, who want to keep seeing the others online without revealing their own presence. But if you want to be online to talk to XMPP-based services but skip Instant Messaging, I think its ok. I assume that if you are really interested on getting presence updates from a particular contact, you would send him a directed presence and become visible just for him. Anyway, in a federated network, I don't see a way to do better than this. If we had a server-2-server protocol for hey, i'm invisible but keep sending those presences, you would be leaking the presence anyway. I'm fine with this XEP as it stands. One nit: third security consideration, about last activity - replying service-unavailable / is a information leak. The proper reply would be to reply with the time of invisible request. This would also leak information :). If you don't want others to know you are online... you might also not want them to know you connected just five minutes ago. Huhs? Sorry, don't follow. last-activity will only reply to people already on your roster. When I move to invisible, I don't want people to know that I'm invisible, so if someone in my rosters asks for last activity, the response should be consistent with my make-believe offline mode: the last-activity is the time of my logout. But what if you want to be Invisible from the beginning of a connection. I don't know the detais of the two invisibility xeps but... it seems just logical that when I connect and start invisible, I don't want my subscribed friends to know when exactly I connected (and disappeared). Maybe I want them to think I was not online at all the whole day. Giving a radically different response when you move from visible to invisible is a clear signature of invisibility. Best regards, -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] invisibility
Hi, On Oct 7, 2008, at 5:45 PM, Pavel Simerda wrote: On Tue, 7 Oct 2008 14:50:35 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 16:50:54 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote: While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? Depends. It defeats the purpose of lurkers, who want to keep seeing the others online without revealing their own presence. But if you want to be online to talk to XMPP-based services but skip Instant Messaging, I think its ok. I assume that if you are really interested on getting presence updates from a particular contact, you would send him a directed presence and become visible just for him. Anyway, in a federated network, I don't see a way to do better than this. If we had a server-2-server protocol for hey, i'm invisible but keep sending those presences, you would be leaking the presence anyway. I'm fine with this XEP as it stands. One nit: third security consideration, about last activity - replying service-unavailable / is a information leak. The proper reply would be to reply with the time of invisible request. This would also leak information :). If you don't want others to know you are online... you might also not want them to know you connected just five minutes ago. Huhs? Sorry, don't follow. last-activity will only reply to people already on your roster. When I move to invisible, I don't want people to know that I'm invisible, so if someone in my rosters asks for last activity, the response should be consistent with my make-believe offline mode: the last-activity is the time of my logout. But what if you want to be Invisible from the beginning of a connection. I don't know the detais of the two invisibility xeps but... it seems just logical that when I connect and start invisible, I don't want my subscribed friends to know when exactly I connected (and disappeared). Maybe I want them to think I was not online at all the whole day. I guess you don't send your initial presence then. First send the invisible IQ, and then set you presence. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] invisibility
On Tue, Oct 7, 2008 at 11:27 AM, Remko Tronçon [EMAIL PROTECTED] wrote: Imho this is not a protocol issue, but a client issue This has been discussed in length before, and the conclusion was that there is no user friendly *and* correct way to do invisibility on top of privacy lists, or any kind of simple operation (such as blocking). Psi has a 'simple' user interface for blocking contacts on top of privacy lists, but if you used *any* other client to do some privacy list operation, then it could break this. We show a warning 'your list may not work', but this is just a horrible user experience. And things get even nastier if you do invisibility, with all kinds of problematic corner cases. Maybe you should look up the original discussion. You cannot fully abstract something that is fundamentally complex. Sooner or later, a user of your abstraction will bump into a problem, and will not understand it unless he understands the concepts underlying your abstraction. (sorry for the delays, but in the last two days of many standards_ml mails went into the spam folder :( ) I agree with the fact there is no general abstraction for privacy lists and there complexity is far beyond the capabilities of the average user (the psi interface for example is of little help if you don't know basic xmpp concepts, and even if you know building them is pretty along task). What I was meaning is just that between adding a new namespace (such as in xep-186) or reusing something already present (xep-126), I prefer the second one. If haven't missed a discussion where xep-126 has been definitely turned down, the main obstacle of a simple privacy list approach is that there is no agreement between client developers in naming the lists associated to basic blocking or invisibility operations, and about when keeping them active (if there are more issues, please point me to the correct discussion, I'm new in this subject, since I've just started studying it for our mobile clients, where we really need fine grained temporary invisibility or unwanted packet blocking). bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] invisibility
Many argue that privacy lists are too complex for invisibility or blocking users. For example, the Pidgin developers. They complained that they need to implement privacy lists completely in order to achieve invisibility and blocking. IMO, we could change the XEP to include some reserved names for priacy lists like blocked or invisible, so that all clients can use them together without any problems. Just setting enabling a privacy thing is easy, the problem is interferences with other clients. This would be solved if we had some reserverd names for privacy lists. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] invisibility
Fabio Forno wrote: (sorry for the delays, but in the last two days of many standards_ml mails went into the spam folder :( ) Hopefully I just put an end to that! I agree with the fact there is no general abstraction for privacy lists and there complexity is far beyond the capabilities of the average user (the psi interface for example is of little help if you don't know basic xmpp concepts, and even if you know building them is pretty along task). What I was meaning is just that between adding a new namespace (such as in xep-186) or reusing something already present (xep-126), I prefer the second one. If haven't missed a discussion where xep-126 has been definitely turned down, the main obstacle of a simple privacy list approach is that there is no agreement between client developers in naming the lists associated to basic blocking or invisibility operations, and about when keeping them active (if there are more issues, please point me to the correct discussion, I'm new in this subject, since I've just started studying it for our mobile clients, where we really need fine grained temporary invisibility or unwanted packet blocking). So this is interesting. In the resource generation thread, we have people trying to fix something that's not broken. In this thread, we have people trying to prevent anyone from fixing something that *is* broken. Human psychology is endlessly fascinating. :) Privacy lists were unnecessary even in the very beginning to solve the problem we thought they needed to solve, which is essentially the following points from RFC 2779: 5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL from subscribing. 5.2.3. It MUST be possible for B to prevent A from receiving notifications, even if A is ordinarily permitted to see such notifications. 5.4.10. B MUST be able to prevent A from sending him messages These requirements could have been solved with simple communications blocking (XEP-0191) instead of privacy lists (XEP-0016), but privacy lists were the hammer we had at that time so we decided to bang the nail with that hammer rather than building something simpler (in part because we misunderstood the requirements from RFC 2779). I submit that the same reasoning applies to invisibility (which was not even a requirement from RFC 2779). Given that so many developers find privacy lists so confusing (not to mention end users!!!), I would very much like to use XEP-0191 and XEP-0186 for blocking and invisibility because they are much simpler for everyone to grok (block this user, go invisible, what could be easier?). If people then feel they need privacy lists for some more advanced functionality, we have the technology ready to use. But I see no good reason to keep hitting these two particular nails with the big sledgehammer we created back in 2002 (does anyone here remember zebra lists?) when much simpler tools can do the job. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] invisibility
On Tue, 7 Oct 2008 17:58:59 +0100 Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Oct 7, 2008, at 5:45 PM, Pavel Simerda wrote: On Tue, 7 Oct 2008 14:50:35 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 7, 2008, at 1:11 PM, Pavel Simerda wrote: On Mon, 6 Oct 2008 16:50:54 +0100 Pedro Melo [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote: While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? Depends. It defeats the purpose of lurkers, who want to keep seeing the others online without revealing their own presence. But if you want to be online to talk to XMPP-based services but skip Instant Messaging, I think its ok. I assume that if you are really interested on getting presence updates from a particular contact, you would send him a directed presence and become visible just for him. Anyway, in a federated network, I don't see a way to do better than this. If we had a server-2-server protocol for hey, i'm invisible but keep sending those presences, you would be leaking the presence anyway. I'm fine with this XEP as it stands. One nit: third security consideration, about last activity - replying service-unavailable / is a information leak. The proper reply would be to reply with the time of invisible request. This would also leak information :). If you don't want others to know you are online... you might also not want them to know you connected just five minutes ago. Huhs? Sorry, don't follow. last-activity will only reply to people already on your roster. When I move to invisible, I don't want people to know that I'm invisible, so if someone in my rosters asks for last activity, the response should be consistent with my make-believe offline mode: the last-activity is the time of my logout. But what if you want to be Invisible from the beginning of a connection. I don't know the detais of the two invisibility xeps but... it seems just logical that when I connect and start invisible, I don't want my subscribed friends to know when exactly I connected (and disappeared). Maybe I want them to think I was not online at all the whole day. I guess you don't send your initial presence then. First send the invisible IQ, and then set you presence. Best regards, I'm sorry, it was not a question, it was a reply to yours. You suggested: The proper reply would be to reply with the time of request. But this breaks the case I have just described and leaks information that you were connected at some specific time. Pavel -- Pavel Šimerda Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] invisibility
Hi, On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote: While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? Depends. It defeats the purpose of lurkers, who want to keep seeing the others online without revealing their own presence. But if you want to be online to talk to XMPP-based services but skip Instant Messaging, I think its ok. I assume that if you are really interested on getting presence updates from a particular contact, you would send him a directed presence and become visible just for him. Anyway, in a federated network, I don't see a way to do better than this. If we had a server-2-server protocol for hey, i'm invisible but keep sending those presences, you would be leaking the presence anyway. I'm fine with this XEP as it stands. One nit: third security consideration, about last activity - replying service-unavailable / is a information leak. The proper reply would be to reply with the time of invisible request. The implication is that the user's information about the presence of its contacts will soon become stale. But I suppose that's one price you pay for invisibility, Right now, I don't see a workaround that would work in a federated network without presence leaks. I can see a smart server having a better behavior for local users, but that's an extension of the server. I think we should allow for servers to keep broadcasting the presence of local users, but say that for external domains, presence will become stale. Basically, leave the door open for invisible with local presences for corporate deployments, but warn that it wont work across the federated network. which I continue to think is a stupid concept anyway. :) Personally I don't care about invisibility. But some of my clients need/want it in a corporate environment... I do see value on selected availability via privacy lists: I want to be online for a certain group of people, not the full roster. But I'm already covered by the current RFCs. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] invisibility
Hi, While reviewing XEP-0186 just now, I noticed that when a resource goes invisible, its server must send presence of type unavailable from that resource. As far as I can see, when a contact's server receives unavailable presence from the user (and if the user+contact have a two-way presence subscription), it will stop sending presence updates to the user (if that was the last online resource for the user). This somewhat defeats the purpose of invisibility, no? The implication is that the user's information about the presence of its contacts will soon become stale. But I suppose that's one price you pay for invisibility, which I continue to think is a stupid concept anyway. :) I thought we gave up with invisibility anyway. Especially that this can be quite easily achieved with privacy lists without those unwanted side effects. And privacy lists give us much more flexibility to set invisibility for a single user, group. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] invisibility
Especially that this can be quite easily achieved with privacy lists I thought we did the contrary: introduce an invisibility extension because: a) Implementing this in a client using privacy lists is quite some work, is not atomic, has nasty corner cases that are hard to solve, and is even harder to implement if you take into account existing privacy lists, and b) Would avoid servers having to implement privacy lists (which is no longer in rfc3920) just to provide invisibility. cheers, Remko
Re: [Standards] invisibility
Am 06.10.2008 um 18:02 schrieb Artur Hefczyc: I thought we gave up with invisibility anyway. Especially that this can be quite easily achieved with privacy lists without those unwanted side effects. And privacy lists give us much more flexibility to set invisibility for a single user, group. Yes, I agree, privacy lists give us all we need for invisibility. Some might see this as abusing privacy lists, but IMO, that's what they are for. They are to block presence or messages to specific users and/or groups. And all users could also be seen as a group. What I personally like about privacy lists: I can have my own invisibility mode, which means I'm invisible to all except a few persons. I can also have more than one invisiblility mode: For example one that just hides me from groups that are often annoying. Ideally, the client would have a sub-menu invisible where I can define my own invisible modes via privacy lists. There's only one thing I'm missing in privacy lists: Time-based privacy lists. So you can say I want to be invisible to group A, B, C etc. from 8pm to 8am. This would be for example useful if you don't want to get annoyed by your co-workers in the evening. The server would then automatically enable the privacy list if you selected a time for it. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] invisibility
Especially that this can be quite easily achieved with privacy lists I thought we did the contrary: introduce an invisibility extension because: a) Implementing this in a client using privacy lists is quite some work, is not atomic, has nasty corner cases that are hard to solve, and is even harder to implement if you take into account existing privacy lists, and b) Would avoid servers having to implement privacy lists (which is no longer in rfc3920) just to provide invisibility. Working alone on such a big project I must admit I am not following all discussions careful enough and I am quite often loosing track of changes in RFCs and XEPs. This is why I was not aware of the conclusion of that discussion. I will try to dig the subject in the list archives to not bring the it back again. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] invisibility
On 28 Aug 2007, at 02:49, Peter Saint-Andre wrote: Kevin Smith wrote: FWIW, I don't agree with the notion that these random resources are a good thing Yes, you have previously expressed that opinion. :) Sorry, I'm not really trying to harp on, I realise this battle has been fought and lost (I'd rather go back to the 'dark days' where we could infer meaning if we wanted to (albeit incorrectly, by rfc)). Well it's another SHOULD-path vs. MAY-path discussion, isn't it? We recommend that you ask your server to generate the resource identifier but say that optionally you can generate one client-side if you want. I was about to say 'but the server can then assign you something unrelated', but then realised that if you don't like the behaviour of your server, you can probably go and find another. I think the solution is simple though; if the server isn't routing your presence to someone, it should reply to iqs on your behalf saying you're not there. This is consistent with the route people have been suggesting recently (and I think I agree with) of 'if you want to start an X session with someone not on your roster, send directed presence first'. I'm not yet sure that's the right approach. I mean, it seems quite reasonable to me (which is why I keep mentioning it), but Ian Paterson has objected that you might want to engage in a stanza session with someone but not share presence (e.g., a Jingle call). Well, there's at least a train of thought that says that it's rather difficult to have a voip call with someone without revealing that you're there ;) I think it's reasonable enough to send directed presence at the start of a chat session, and revoke it afterwards. You don't disclose any aditional information that way than you would do just by having some stanza exchanging session. /K
Re: [Standards] invisibility
Kevin Smith wrote: On 28 Aug 2007, at 02:49, Peter Saint-Andre wrote: Kevin Smith wrote: I think the solution is simple though; if the server isn't routing your presence to someone, it should reply to iqs on your behalf saying you're not there. This is consistent with the route people have been suggesting recently (and I think I agree with) of 'if you want to start an X session with someone not on your roster, send directed presence first'. I'm not yet sure that's the right approach. I mean, it seems quite reasonable to me (which is why I keep mentioning it), but Ian Paterson has objected that you might want to engage in a stanza session with someone but not share presence (e.g., a Jingle call). Well, there's at least a train of thought that says that it's rather difficult to have a voip call with someone without revealing that you're there ;) I think it's reasonable enough to send directed presence at the start of a chat session, and revoke it afterwards. You don't disclose any aditional information that way than you would do just by having some stanza exchanging session. Agreed. I will formulate some proposed text along these lines for rfc3921bis, i.e., both for we suggest that you share presence for a stanza session with an unknown person and for the server should answer on behalf of IQs to the full JID if you're not sharing presence. Then we'll run it up the flagpole and see who salutes. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] invisibility (was: Re: xep-0199 redundancy)
On 27 Aug 2007, at 17:28, Peter Saint-Andre wrote: We had a long long discussion thread about this a few months ago, as a result of which we modified rfc3920bis to recommend the use of random resource identifiers that are generated by the server, not the client. FWIW, I don't agree with the notion that these random resources are a good thing (I'd rather go back to the 'dark days' where we could infer meaning if we wanted to (albeit incorrectly, by rfc)). I think the solution is simple though; if the server isn't routing your presence to someone, it should reply to iqs on your behalf saying you're not there. This is consistent with the route people have been suggesting recently (and I think I agree with) of 'if you want to start an X session with someone not on your roster, send directed presence first'. /K
