[Standards] PEP + Invisibility = bad behavior?

Peter Saint-Andre stpeter at stpeter.im
Wed Apr 23 04:05:12 UTC 2008

Gabriel Soto wrote:
> I'll start with a question:
> When a user publishes a PEP item [1], should the server send
> notifications to appropriate contacts that appear offline?
> I've been told that the answer is probably no, it shouldn't, which makes sense.
> The first potential problem here is that this isn't explicitly stated
> in the XEP and maybe it should.

I think it is stated in Section 13.1 of XEP-0060, which says that one
possible trigger for sending a notification is:


4. The entity is not subscribed but is eligible to do so and has sent
presence containing appropriate entity capabilities data to a service
that supports filtered notifications (effectively establishing a
"temporary subscription"); when the publisher sends a publish request
that matches the entity's expressed notification interests, the service
sends the currently published item to the entity.


But it probably could be clearer, for example in Section 10.1.3.

> The second potential problem is that I believe this behavior clashes
> with some mechanisms that rely on 'faking' offline presence (i.e.
> blocking, invisibility).
> For instance, when userA becomes invisible to userB [2] he will appear
> offline to him. Then, if userB updates his avatar (publishes a PEP
> item) userA doesn't receive the corresponding notification.
> This seems like an unwanted side effect. If invisibility is an option,
> I think that the expected behavior from a user's perspective will be
> that everything works the same except for the offline appearance to
> others.

Personally I don't care about invisibility. If you want to get some, you
have to give some. Life is hard.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080422/9406c102/attachment.bin>

More information about the Standards mailing list