XSF Discussion - 2020-09-02


  1. Guus

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

  2. 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.

  3. jonas’

    do the latter and tell clients not to do that

  4. jonas’

    for sync, IDs are the only safe way

  5. jonas’

    for ephemeral display, times are OK

  6. Guus

    Educating users. What could possibly go wrong...

  7. jonas’

    s/users/developers/!

  8. 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...

  9. jonas’

    that sounds like an excellent way to DoS openfire

  10. Guus

    There are easier ways.

  11. Holger

    Heh, creative solution! 🙂

  12. flow

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

  13. flow

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

  14. 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 🙂

  15. 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"

  16. jonas’

    Ge0rG, but then not for "end"

  17. Ge0rG

    jonas’: yes

  18. Ge0rG

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

  19. Ge0rG

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

  20. Kev

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

  21. jonas’

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

  22. Kev

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

  23. 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.

  24. jonas’

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

  25. Kev

    Indeed, that seems to be correct behaviour to me.

  26. jonas’

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

  27. jonas’

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

  28. Zash

    We need to use error type=continue for something!

  29. 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?

  30. jonas’

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

  31. lovetox

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

  32. 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

  33. 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

  34. 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

  35. Zash

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

  36. 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

  37. Zash

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

  38. lovetox

    thats a bad idea

  39. lovetox

    that would trigger another query

  40. lovetox

    so endless loop

  41. lovetox

    we had that with biboumi a year ago

  42. 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/

  43. moparisthebest

    I think you ping emus ^

  44. pep.

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

  45. 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.

  46. jonas’

    dwd, next doors

  47. jonas’

    dwd, next door?

  48. jonas’

    (council@)