jdev - 2020-08-18

do you guys have some script to cleanup old presences in your clients ?

what does that mean?

or is there some rule that exists to explain that

what are old presences?

what is happening if you have a client that receives a presence and nothing else for days but stays connected

nothing?

nothing else from the other jid

let me rephrase that

why is that a problem?

well after 5 days you can maybe think that somehow those presences are not valid anymore

how could that be?

well, regarding by your questions I have a feeling that it's not a problem :p

edhelas: it's only a problem if you have significant loss on your s2s links

It may well be a 24/7 (mobile/terminal/whatever) client that manages to keep the session alive, of course. But yes it may also be borked s2s. Who cares about presence anyway :-)

edhelas, as a client, you can’t do a lot, except cycling your session :)

I care about presents!

a server can send type="probe" presence stanzas to refresh

i'm just seing some old presences in the movim db after a few days, and i was wondering that, might be a bug

I'm logged into my server for 9 days now

which coincidentally is the uptime of the server

this causes issues with https://xmpp.org/extensions/xep-0319.html

Related https://issues.prosody.im/904

jonas’: But then you likely get only the new presence. Stale presence where the unavailable got lost would not get an unavailable unless you count one for the entire account.

I'm not so sure about 319. I've seen almost flood amounts of presence where 319 is the only diff.

Zash, huh?

type="probe" SHOULD be answered with unavailable if the peer is offline

and an unavailable from the bare JID should count for all resources, in general, shouldn’t it?

Yes

But if you have another resource online

ahhh

One that is different from what you think is online

and there is no "end" marker...

That's where it gets tricky and you'll need some smart tracking / caching magic

yeah

I can come up with some, you can probably too.

Sure.

Doesn't strike me as an urgent enough problem tho, not when it'll have a memory cost.

wait clients can't send probes?

nope

https://tools.ietf.org/html/rfc6121#section-4.3

Presence probes SHOULD NOT be sent by a client, because in general a client will not need to send them since the task of gathering presence from a user's contacts is managed by the user's server. However, if a user's client generates an outbound presence probe then the user's server SHOULD route the probe (if the contact is at another server) or process the probe (if the contact is at the same server) and MUST NOT use its receipt of the presence probe from a connected client as the sole cause for returning a stanza or stream error to the client.

well clients SHOULD NOT send probes

so you can!

I thought Dino did

why would you tho

iunno

Perhaps of interest / relevance: https://xmpp.org/extensions/xep-0310.html

Tho still needs server-side caching/tracking of remote presence

Altho, synthesizing an annotated unavailable bare-jid presence on (detected) s2s failure could work, and then you queue probes for when s2s comes back.

there are cases when you want to presence probe

although not very relevant ones

for example if you use privacy lists

when you remove some blocking presence rule, then you have to presence probe

i dont think a server does that for you

it does though in blocking command xep which is nice