jdev - 2026-07-27

MattJ: can your share your riddim framework source

in your website, it redirects to 404

https://matthewwild.co.uk/projects/riddim/

I've been working on CSI optimisation. Openfire's existing support simply buffers, and I'm starting to work on dropping superceded stanzas. Does anyone have any lists of what stanzas can be elided in this way? So far I have presence (available+unavailable) and CSN (composing etc). Any other things worth doing?

I'm not sure anyone is doing that yet, but it sounds fun!

dwd: maybe displayed markers? But could be not wanted

multiple edits to one item? heh, but that'll mess up vs mam so no

lovetox, Oh, displayed markers is interesting, because by definition a "later" marker subsumes an "earlier" one. But are we sure they're always sent in order?

and that they don't go to mam, heh

singpolyma, I work on a system where they do, interesting point.

of course they go to MAM, but what would be the problem wth that singpolyma,

If they go to MAM and your CSI skips them, now what you've seen in the app is out of sync with what's actually in the MAM

yeah .. but you dont "see" displayed markers

except for a checkmark somewhere

But that's solvable by ensuring any stanza containing a stanza-id from the server doesn't get CSI-squashed.

a chatstate gets also a stanza-id ..

lovetox, Does it? I don't think Openfire stores "standalone notifications" in MAM.

i mean .. i didnt think this has relevance for CSI, if its stored in MAM or not

but yeah displayed markers are a bit different, my concerns would be, if some clients still want to get all displayed markers

lovetox, Hmmm... Intuitively it feels like it might. Holes in MAM. Feels like it could cause a problem? But I don't know for sure.

even if they are old, because it still conveys the information at which point in time someone read up to which message

i would vote against squasing displayed markers, was just the only thing left that came to mind

Openfire doesn't support MAM properly in one-on-one dwd .

I should probably fix that, too...

There's an outstanding issue about stanza IDs not being applied apart from in MUC context. That's the crux of several issues.

I actually thought all the other servers were doing Clever Things with CSI already.

I’d certainly expect that if the server starts failing to send messages to a client that have been archived it’s going to screw up at least some client synch mechanisms.

It does seem likely.

Although we may both be wrong.

I can only actually think of failure cases the other way around - where the server doesn't persist messages that have been stamped with a stanza-id.

https://discourse.igniterealtime.org/t/monitoring-plugin-mam-doubled-quadrupled-messages-after-relogin/94112

this gets regulary reported to the Gajim tracker

last time i had to reject a AI generated PR that "solved" the problem in Gajim :D

I'll make a AI-generated PR to fix it in Openfire, then...

but it happens regulary that people now fix their problems by telling the AI to adapt the code

with python applications that works great, because there is no compiling involved, they can simply point them to the files on the harddisk

Oh, I'm sure. Everything always follows the Garbage-In, Garbage-Out rule.

im waiting for the first bug reports of these self fixed deployments :D