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
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
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
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
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
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
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 ;-)
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
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.
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
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,
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
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
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
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
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
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
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 ;-)
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
51 matches
Mail list logo
