When filtering a MAM archive by time, what is the desired/expected behavior if the specified time is some instant in the future?
karoshihas left
karoshihas joined
Guus
Returning an error might cause issues with systems that have drifting clocks. Returning a result might cause the client to think that all messages up to that point in time have been synced.
jonas’
do the latter and tell clients not to do that
jonas’
for sync, IDs are the only safe way
adiaholichas left
jonas’
for ephemeral display, times are OK
adiaholichas joined
Guus
Educating users. What could possibly go wrong...
jonas’
s/users/developers/!
Guus
Openfire currently delays the response until that time has reached. Works for drifts, I think, but we had an ever running request just now...
adiaholichas left
adiaholichas joined
sonnyhas left
sonnyhas joined
rionhas left
rionhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
jonas’
that sounds like an excellent way to DoS openfire
lorddavidiiihas left
karoshihas left
sonnyhas joined
karoshihas joined
Guus
There are easier ways.
sonnyhas left
adiaholichas left
adiaholichas joined
lorddavidiiihas joined
amuza@riseup.nethas left
amuza@riseup.nethas joined
adiaholichas left
papatutuwawahas left
Andrzejhas joined
krauqhas left
krauqhas joined
ralphmhas left
ralphmhas joined
papatutuwawahas joined
adiaholichas joined
Holger
Heh, creative solution! 🙂
intosihas left
Andrzejhas left
papatutuwawahas left
papatutuwawahas joined
Andrzejhas joined
flow
shouldn't mam queries with an 'end' value that is potentially affected by time drift simply not contain an 'end' value?
flow
or is their intention something else than "give me all messages (starting from X) up to now"?
adiaholichas left
Guus
I don't know. From what I notice in the logs, at least someone is putting in an 'end' value for reasons beyond me 🙂
Ge0rG
The only excuse to use timestamps in MAM is when the client wasn't active for an eternity, and you only want "the last 14 days of history"
jonas’
Ge0rG, but then not for "end"
Ge0rG
jonas’: yes
Ge0rG
But then again, there is no way to ensure there is a no-overlap no-holes connection setup.
Ge0rG
So developers might be inclined to use timestamps to reduce the overlap or hole
Dele Olajidehas left
Kev
I think that's outright wrong. There are a number of good reasons to search an archive using timestamps.
jonas’
(that’s what I meant by "ephemeral display" fwiw)
Kev
And I can even see why a naive implementation might end up requesting dates in the future
sonnyhas joined
Kev
Let's say you've got a renderer that shows a day's history at a time, you might end up requesting 'the end of today' instead of adding logic to check if it's today and removing the end from it.
jonas’
hence my suggestion to simply truncate at $now and return immediately
Kev
Indeed, that seems to be correct behaviour to me.
sonnyhas left
sonnyhas joined
jonas’
you could also return an IQ type='error' <error type='continue'/> if you’re fancy and want to break everyone✎
jonas’
you could also return an IQ type='error' <error type='continue'/> if you’re fancy and want to break everything ✏
Zash
We need to use error type=continue for something!
Dele Olajidehas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
intosihas joined
Nano4BeingYouhas joined
mukt2has joined
adiaholichas joined
sonnyhas left
Dele Olajidehas left
adiaholichas left
karoshihas left
karoshihas joined
adiaholichas joined
Andrzejhas left
flow
Would it be sensible to add a note to xep313 to not use 'end' == now, but instead omit 'end', to avoid issues with holes where end < now?
jonas’
if you want to avoid holes, don’t use timestamps
lovetox
flow does the xep not mention what a missing end attribute does already?
flow
lovetox, probably, but that appearantly does not prevent developers from setting end=now. Not that I believe a note would change much, but at least it is documented
neshtaxmpphas joined
flow
I think I personally would favor erroring queries with a timestamp in the future, so that developers are forced to re-think their design. But I know that my "fail hard and fast (per default)" - whatever that actually means is subjective - is not undisputed✎
flow
I think I personally would favor erroring queries with a timestamp in the future, so that developers are forced to re-think their design. But I know that my "fail hard and fast (per default)" ideology - whatever that actually means is subjective - is not undisputed ✏
mukt2has left
karoshihas left
Zash
Pretty sure Prosody just turns it into a query equivalent to `WHERE "when" BETWEEN ($start AND $end)`
flow
Kev gave a nice example why erroring on such queries may be not a good idea, but I think I would favor that tiny little bit of extra client logic, over the (granted, probably small) possiblity that clients end up with holes
karoshihas joined
lorddavidiiihas left
Zash
What if you cheat and set the 'complete' flag to false?
amuza@riseup.nethas left
Andrzejhas joined
karoshihas left
adiaholichas left
sonnyhas joined
karoshihas joined
krauqhas left
krauqhas joined
thorstenhas left
adiaholichas joined
lovetox
thats a bad idea
alameyohas left
alameyohas joined
lovetox
that would trigger another query
thorstenhas joined
lovetox
so endless loop
lovetox
we had that with biboumi a year ago
lorddavidiiihas joined
sonnyhas left
sonnyhas joined
lorddavidiiihas left
sonnyhas left
karoshihas left
sonnyhas joined
mukt2has joined
lorddavidiiihas joined
thorstenhas left
thorstenhas joined
Steve Killehas left
neshtaxmpphas left
karoshihas joined
thorstenhas left
thorstenhas joined
sonnyhas left
neshtaxmpphas joined
adiaholichas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
mukt2has left
lorddavidiiihas left
adiaholichas joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
Steve Killehas joined
adiaholichas left
adiaholichas joined
Dele Olajidehas joined
adiaholichas left
adiaholichas joined
mukt2has joined
Shellhas joined
debaclehas left
flow
how do I suggest items for the xmpp newsletter? writing here? if so → https://www.netways.de/blog/2020/08/28/zurueck-in-die-zukunft-icinga2-benachrichtigungen-mit-xmpp/
mukt2has left
moparisthebest
I think you ping emus ^
pep.
You can PR against https://github.com/xsf/xmpp.org/pull/756
emus
flow: yes, what pep. says. If you write a short text for it, what would be really helpful, it is just fine to comment there or in the CommTeam MUC as well.