XSF Discussion - 2020-09-02

When filtering a MAM archive by time, what is the desired/expected behavior if the specified time is some instant in the future?

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.

do the latter and tell clients not to do that

for sync, IDs are the only safe way

for ephemeral display, times are OK

Educating users. What could possibly go wrong...

s/users/developers/!

Openfire currently delays the response until that time has reached. Works for drifts, I think, but we had an ever running request just now...

that sounds like an excellent way to DoS openfire

There are easier ways.

Heh, creative solution! 🙂

shouldn't mam queries with an 'end' value that is potentially affected by time drift simply not contain an 'end' value?

or is their intention something else than "give me all messages (starting from X) up to now"?

I don't know. From what I notice in the logs, at least someone is putting in an 'end' value for reasons beyond me 🙂

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"

Ge0rG, but then not for "end"

jonas’: yes

But then again, there is no way to ensure there is a no-overlap no-holes connection setup.

So developers might be inclined to use timestamps to reduce the overlap or hole

I think that's outright wrong. There are a number of good reasons to search an archive using timestamps.

(that’s what I meant by "ephemeral display" fwiw)

And I can even see why a naive implementation might end up requesting dates in the future

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.

hence my suggestion to simply truncate at $now and return immediately

Indeed, that seems to be correct behaviour to me.

you could also return an IQ type='error' <error type='continue'/> if you’re fancy and want to break everything ✏

We need to use error type=continue for something!

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?

if you want to avoid holes, don’t use timestamps

flow does the xep not mention what a missing end attribute does already?

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

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 ✏

Pretty sure Prosody just turns it into a query equivalent to `WHERE "when" BETWEEN ($start AND $end)`

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

What if you cheat and set the 'complete' flag to false?

thats a bad idea

that would trigger another query

so endless loop

we had that with biboumi a year ago

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/

I think you ping emus ^

You can PR against https://github.com/xsf/xmpp.org/pull/756

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.

dwd, next door? ✏

(council@)