[Standards] Delayed Delivery for CSI and possibly SM

Kevin Smith kevin.smith at isode.com
Tue May 30 14:50:16 UTC 2017

On 30 May 2017, at 15:37, Daniel Gultsch <daniel at gultsch.de> wrote:
> 2017-05-30 16:28 GMT+02:00 Kevin Smith <kevin.smith at isode.com>:
>> On 30 May 2017, at 15:18, Daniel Gultsch <daniel at gultsch.de> wrote:
>>> 2017-05-30 16:02 GMT+02:00 Dave Cridland <dave at cridland.net>:
>>>> Presence, mind, I'm not so sold on - I think it's significantly less
>>>> important, since presence is stateful rather than an event. But I'm
>>>> not averse to it - I'd just argue that if it causes problems, just
>>>> don't bother delay-stamping.
>>> I have no hard feelings regarding presence however if we stamp with
>>> the account jid it wont cause problems.
>>> And people are really obsessed with 'Last Seen' Whatapp-like
>>> information. (That's how I stumbled over the problem in the first
>>> place.) So in their interest it would really help to have a more
>>> detailed time information on presence as well.  (Mind you CSI can
>>> easily delay those information by multiple hours)
>> I’m not sure, given the peculiarities of presence probes and S2S and etc., that using presence for this is particularly reliable. I could wrong (again).
> For this kind of audience and in lack of a 'proper' mechanism for this
> faking it seems to be good enough.

Yes, that may be.

> Also stamping presences is done elsewhere as well. (Presences received
> after signing in are usually stamped).

Only the ‘offline’ presences, because they’re delayed, though. ‘Live’ presences aren’t.

> A lot of clients show
> 'Available since…' or 'Away since…' information somewhere in the UI.
> So reliable or not SM/CSI should not behave different here.

I think I’m arguing that stamping presence on SM/CSI *is* behaving differently.


More information about the Standards mailing list