jdev - 2023-11-11

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)

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

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

but good catch

jonas’, thanks

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

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

Not that I'm aware of

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?

thats the idea

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?

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

singpolyma, i think what you are describing can never happen

the protocol is incapable of "missing" an ack

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"

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

singpolyma, sounds correct

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

and maybe it can also ignore <r/> ?

bascially you receive a count everytime you request

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

this count will always rise

and you adjust your queue accordingly

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

correct

makes sense, thanks

and the server has the same thing in the other direction

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

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

right, that makes sense

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

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

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

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

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

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

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

so considering this right from the start makes sense