Gajim - 2024-05-30

Can't seem to find the OMEMO plugin as mentioned in this Arch wiki page: https://wiki.archlinux.org/title/Gajim#OMEMO_support

epic: its built in now iirc

. ✏

amogus: nice. Might look into which OMEMO version is being used, but I assume (siacs,0,1)

does gajim always store dates/times in epoch time? In other words, does gajim ever store dates/times in local time? ✏

In nightly, message search times are always shown in UTC, regardless of what timezone I have set

yes this is a display bug

lovetox pushed 1 commits to branch gajim/master cfix: SearchView: Display rows with localtime - https://dev.gajim.org/gajim/gajim/-/commit/5ec9ff00417e887817b8aed54d370521a4e4be9c

should be fixed

now we have a new bug with the date header ...

lovetox pushed 1 commits to branch gajim/master cfix: SearchView: Separate chats correctly - https://dev.gajim.org/gajim/gajim/-/commit/7bb24f15f180b5e85ebe4056e097b3c162b379e6

hi! first of all, wanted to say that i love Gajim, it's probably the best Linux XMPP client.

https://xmpp.gabets.me:5443/upload/d6ebd51d8b2f81a7cbb4f7d7203eb4fec8657b4a/44tjq8UQ5Eu18CmDmmzug4boKi7sbBnsHjUFMgiE/white_top_bar.png

i noticed that on Windows, the header/title bar for the Gajim window is white even when dark mode is enabled on Windows and/or dark mode is explicitly enabled in Gajim. is this intended or is this an issue that needs to be fixed? to me, it would make sense if the title/header bar follows the theme of Gajim / Windows.

in my opinion its the job of windows to style the window

Could be a problem with the GTK framework, at least we dont control this in the application

i agree that it's windows' job to style the headers. but it's weird that all other windows get styled correctly, but Gajim's doesn't. makes me wonder if the issue lies with Gajim. is anyone else experiencing this on Windows?

i don't know enough about windows applications to know where the issue lies or how to fix it

i suspect it lies with the gui framework we use GTK

you can open an issue on the tracker if you want

opened an issue on the topic

Yesterday I had exchanged a few PMs in this room and and today in Gajim the last 8 received messages are displayed twice. My own sent messages are not affected as and neither older messages. Weird. :)

The dups stay when restarting Gajim or switching the chat. So it's not just a visual issue. ✏

check the database, if the stanza-id is the same

the stanzas ID are different

1717013675478911 1717013675479231

the `id`s however are the same.

i suspect some kind of ejabberd bug

it puts the message twice in the archive

but on Conversations and Cheogram (on the same phone) the messages are not duplicated up to now.

though those I received iirc when I was online and were not fetched later from any archive as in the Gajim case

also other clients might use different measures to check for duplicates

but this sounds definitly like a server bug, stanza id needs to be unique for one message

ok

if there are 2 messages with different stanza id Gajim needs to assume its two different messages

because message-id does not need to be unique, a client could simply add no message-id at all, would also perfectly legal

i suspect it has something to do with carbons of MUC PMs

sounds reasonable

but seems its not easily reproduceable

it was incoming messages that were duplicated or?

hm no i cant reproduce it at will

which also shows for me that its not a simple bug where Gajim does not deduplicate messages

there are certain conditions under which the server logs this message twice

for whatever reason

> it was incoming messages that were duplicated or? yes ↺

lovetox, I can perfectly reproduce it, though ofc the circumstances are bit unusual: 1) Have the same account A on Gajim, Conversations and Cheogram (on the same phone) 2) A is logged on Gajim but logged in both apps on the phone 3) Have a second account B on Gajim and send A a pm in this MUC 4) Go online with Gajim with account A

I had the two apps on the phone running b/c I wanted to try out Cheogram for the 1st time.

hm i tested only with 2 devices

maybe it happens only with 3

yes, if I am not logged in Cheogram _or_ Conversations, it doesn't happen

you need to be logged in in both at the same time ✏

2) A is *not* logged in Gajim* ✏

yeah

ok but then its easy to find evidence

if you go online with Account A in Gajim in 4)

can you gather the xml log, and then we should see 2 stanzas coming from mam with the same content

this evidence and the reproducer we could open a ejabberd issue

let me check

Here's the XML output: https://conference.gajim.org:5281/pastebin/0aa034d7-66fd-49ef-8201-c2b998766586

The message is indeed archived twice: > <archived by="jidA@conversations.im" id="1717073780134445" xmlns="urn:xmpp:mam:tmp" /> > <archived by="jidA@conversations.im" id="1717073780134971" xmlns="urn:xmpp:mam:tmp" />

Can you open a issue on the ejabberd tracker?

I'm also having issues with duplicated messages but I suspect it's an ejabberd issue because it doesn't happen with every server

it only happens in gajim tho, but it's difficult to reproduce

both sent and received. weird that some sent messages are marked with the received colors as if it wasn't me

Here we go: https://github.com/processone/ejabberd/issues/4227

still seems to be a bias for IPv4 over IPv6 in glib-networking

anyone else notice it?

I tried other happy eyeballs tests in the past... and 99% of the time it picked IPv6... for some reason glib-networking (and any application which uses it) prefers IPv6, a friend just had the same issue too

Happy eyeballs means connect to the one that returns DNS faster

I see sqlalchemy (2.0.30+ds1-2) has just entered Debian unstable

fwiw, I've been experiencing an uptick in duplicate messages in the past month or so

cal0pteryx: yea, ogg is understood by Conversations

opus/ogg

Observation about the three default reaction buttons: I find it a little bit cluttered and wonder if less would be more. E.g. in Dino there are no default reactions and it looks somehow "cleaner", certainly simpler. I wonder, if they can be removed?

We finally got a complaint 😂. I feel a bit torn on the issue. I personally won't be using the default buttons much. The reply button absolutely must be single click, though.