jdev - 2025-03-01

moparisthebest, why that, “especially in python”?

Link Mauve: just because https://docs.python.org/3/library/pickle.html

moparisthebest, we kept the pickle compatibility in the new JID implementation in slixmpp 1.9.0, don’t worry.

So even if you parse it as a resourcepart with all of the resourceprep, it will work.

Although, I don’t think we expose a specific resourcepart type atm.

Not sure what you mean, I'm just saying a private pep node is an untrusted source so pickle shouldn't be used on it

Does pickle support XML as a source or destination? I thought it was only a binary serialization of Python objects.

Pickle > base64 > pep node; seems like something python might do

Python doesn’t do stupid things on its own, you have to very knowingly do such a thing. And shouldn’t.

I think that's all I said?

No you said "python might do"

I'm promoting Gajim in the list of alternative clients in Movim now :)

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/PHSlSUIqlNGk/chat_image.png

That's great :) thanks a lot

Fully featured is sadly a bit of an overstatement in recent times

More than any other client still 🙂

Really? If I think about any feature related to jingle, Gajim is now at zero.

I guess it depends on what you need.

other than cheogram, does gajim miss any features another client has?

edhelas: Can you update the copyright year?

qy: you can check with https://xmpp.org/software/software-comparison/

Though we need to update Gajim's DOAP file

qy: just A/V

> qy: just A/V 👍 ↺

Soon ™

> No you said "python might do" Right. Certain languages are notoriously vulnerable to RCE during deserialization due to having vulnerable methods in the stdlib to do it. Python, PHP, and Java are examples. ↺

Guus, does openfire store message timestamps with sub second precision?

lovetox, in what/where? MAM?

yes

last recorded timestamp in the database is 1740859932353

that's milliseconds

great

thanks

np

(unsure if it _communicates_ with the same precision, but that's likely_

yeah, i guess thats easy to fix if it would not be the case

why are you looking into this?

if you "backload" MAM history, means you have already messages from today, but you want to load more messages from yesterday, and you store these messages into a local client database, its very complex to load them later back into the GUI with the correct order of messages

This becomes easy if you can depend on that each message has a different timestamp

i know subsecond precision not exactly gives this guarante, but in practices it will almost never happen, close enough

... that. :)

but why look at Openfire specificially?

the problem is with only second precision, it happens daily

because ejabberd, and prosody already have subsecond precision

and i wanted to check other server implementations, if most of them have it, i would try to implement it

ah, ok