jdev - 2023-11-11

  1. cal0pteryx

    any slixmpp/poezio devs here? https://slixmpp.readthedocs.io points to lab.louiz.org, which seems to be dead. I vaguely remember somebody saying they moved to codeberg? if so, those links should be updated. also their DOAP links are failing (same host issue)

  2. jonas’

    cal0pteryx, https://codeberg.org/poezio/slixmpp

  3. jonas’

    the place to ask is probably xmpp:poezio@muc.poez.io?join

  4. jonas’

    but good catch

  5. cal0pteryx

    jonas’, thanks

  6. pep.

    I think lab.louiz.org was supposed to redirect but not sure if that works

  7. Zash

    Did any client implement the raw iq vcard4 protocol (now removed from the XEP)?

  8. singpolyma

    Not that I'm aware of

  9. singpolyma

    How are clients usually using stream management? Do you queue outbound stanzas until you get an ack for them? I guess in the case of a resume one could then resend any difference between the queue and what the server gives as a count during resumption?

  10. lovetox

    thats the idea

  11. singpolyma

    and I guess if an ack missing something in the queue you just assume the server didn't get to it yet, but you don't error or resend until resumption or failed resumption, yeah?

  12. Zash

    singpolyma, could you rephrase that, not sure I can parse it correctly

  13. lovetox

    singpolyma, i think what you are describing can never happen

  14. lovetox

    the protocol is incapable of "missing" an ack

  15. singpolyma

    If I send <r/> and have sent 3 stanzas and I get <a/> and it says 2,I treat two of my three as ack and just assume the third will be ack "next time"

  16. Zash

    You ack by sending a number, which acks every stanza in the queue up to that number.

  17. lovetox

    singpolyma, sounds correct

  18. Zash

    Server can both send <a/> whenever it wants, so it could try to ack something from a few stazas before you sent your <r/>

  19. Zash

    and maybe it can also ignore <r/> ?

  20. lovetox

    bascially you receive a count everytime you request

  21. Zash

    But you can't count on the next <a/> you receive correspond to any particular <r/>

  22. lovetox

    this count will always rise

  23. lovetox

    and you adjust your queue accordingly

  24. singpolyma

    right. and so long as I'm still connected I just assume everything is fine and I only actually do anything with the queue during a resume

  25. lovetox


  26. singpolyma

    makes sense, thanks

  27. Zash

    and the server has the same thing in the other direction

  28. lovetox

    if you build this new, i would suggest that you give your library the ability to communicate somehow which stanzas where removed from queue and are therefore "acked".

  29. lovetox

    This allows your client to build fancy things like showing the user when a message was successfuly sent to the server

  30. singpolyma

    right, that makes sense

  31. Zash

    Perhaps some enum-ish state that goes upwards from queued → 198-acked → 184-acked → 333-displayed?

  32. lovetox

    the thing is with sm, it sounds easy enough at first, you think about resending on resume

  33. lovetox

    but then, can you guarantee there will be a resume?

  34. lovetox

    now suddenly you need UI to indicate to the user that messages didnt reach the server

  35. lovetox

    do you still want to automatically resend on reconnect? now you need logic for that, what if its after a day? probably not, now you need UI so the user can decide himself if he wants to resend ..

  36. Zash

    probably varying by stanza as well. users probably want at least the choice of resending messages, but random presence or iq stanzas should probably be discarded

  37. lovetox

    this can be all improved gradually but basis for all of that is, that the lib tells the client which stanzas have been acked

  38. lovetox

    so considering this right from the start makes sense