Gajim - 2024-05-02

Are the gajim nightly debs working? When I try to update apt tells me there's no update even though I have a version from november

> we cannot build debian packages right now > because sqlalchemy, a new dependency is not in debian unstable > you can use flatpak singpolyma: that's from lovetox on april 14

> nicoco, are there any lmitations on some bridges Gajim should know lovetox: as much as possible slidge replies with error stanzas on operations that are not permitted. I wonder if nick change attempt is covered though? Slidge uses the thing were it forces your nickname when you join a room, no matter the one you tried to use and gajim supports this nicely already (most clients actually, beagle is the only one I use that still don't respect this part of XEP-0045)

> There's a working and recommandable WA bridge? meson: yes there is ;) https://git.sr.ht/~nicoco/slidge-whatsapp

lovetox: I just tried specifically to change my nickname and slidge just silently ignores the "nickname change presence", which is not correct, apparently it should reply with this https://xmpp.org/extensions/xep-0045.html#example-53 -- there's always new stuff to be found in XEP-0045 😆️ I've opened https://todo.sr.ht/~nicoco/slidge/196 - I don't think (but maybe didn't search hard enough) there's a way for MUCs to tell clients in advance that it's not possible to change their nickname, so that the option would be just grayed out in gajim's UI?

Also, since you're mentioning bridge support in gajim, there's this very small PR waiting for feedback https://dev.gajim.org/gajim/gajim/-/merge_requests/988 - it just adds the "transport icon" to MUC avatars, just like gajim already does for contact avatars.

I ask because we could additionally disable it in Gajim

For specific gateways

For most (maybe all?) networks supported by slidge, there is no notion of "muc-specific nickname" (maybe discord has somehow? I should check that someday)

It doesn't feel right to make this transport-specific IMHO, but I think MUCs in general should advertise in their disco info (or muc config form or something) if it's not possible to rename oneself in there. ✏

GG with XEP-0461 guys! I'm already opening tickets about it 😁️

But it's pretty cool to have the feature :)

> GG with XEP-0461 guys! I'm already opening tickets about it 😁️ That's great! :) ↺

lovetox pushed 2 commits to branch gajim/master refactor: MessageRow: Use kwargs for clarity - https://dev.gajim.org/gajim/gajim/-/commit/91078eb7b759c0c986ca775964db3c727f4d243d refactor: Pass only original message around - https://dev.gajim.org/gajim/gajim/-/commit/5f12092a14aea923a4a0e37a0eedc4a4448a37e8

I'm pretty excited by the addition of message replies. Thanks guys!

has anyone noticed an increase of disk activity and startup time when starting up gajim since the new database layout? ✏

and I mean it looks like an abnormal amount of disk activity. I haven't measured yet.

lovetox pushed 1 commits to branch gajim/master cfix: ArchiveStorage: Don’t fail there is no message found - https://dev.gajim.org/gajim/gajim/-/commit/40aba5bde85bc98b224b7b8a66ac3a64c547af34

Hahaha lovetox I just opened a PR for this one xD

This is a bugfixing race!

sorry :)

> has anyone noticed an increase of disk activity and startup time when starting up gajim since the new database layout? Not really, but I have a fairly fast SSD… ↺

lovetox: before fixing more, here's another short one: https://dev.gajim.org/gajim/gajim/-/merge_requests/1039

although I'm not 100% if it should be with or without fallback in here

it doesnt matter, the value in the dict is never used

pretty annoying that the type checker didn't catch this one!

it did for me

we just dont check that module

because it has too many other errors

Oh OK, I guess I meant "CI didn't catch this one" because sure, my IDE too underlined it :)

could you change it so we assign the res from get_text() to some variable

because it will be then needed twice in that method

sure

and your commit message is not great :D

dont make the prefix part of the statement

the prefix will be gone later, we have prefixes so the changelog tool takes the message and puts it into the changelog

if you do fix: Sending Message

cfix: Fixes sending OMEMO-encrypted messages in MUCs

is that good?

later in the change log it will just say "Sending Message"

yes, I'm very jealous of your autochangelog thing, I need to set it up for slidge :) ✏

yes thats better

or even better "Fix"

if you didnt see it yet in our contributing file

https://chris.beams.io/posts/git-commit/

there you go

lets say i try to write my commit messages with that guide in mind

not always succeeding at it of course

and when i think about a commit message for more than 60 seconds, sometimes i give up :D

I read various blog posts about good commit messages, but then as with a lot of other things, I forget to apply it quite often :)

> and when i think about a commit message for more than 60 seconds, sometimes i give up :D 😆️ (yes, we need 0444 now) ↺

> and when i think about a commit message for more than 60 seconds, sometimes i give up :D I know that feeling with bug report titles

Is there any downside or possible pitfall with alternating between different databases or different installs of gajim on the same accounts? Will catching up on MAM sync on one install or database result in the other not downloading messages? Where is the mam sync state stored?

dont waste your time

not sure what you are trying to show, yes we request a lot more data from the database, thats expected if you go from 3 to 12 tables

nicoco, did you push your changes?

MR looks the same

I was asking for reasons of general testing, not just disk activity. But the disk activity looks crazy, so I'll look into that too.

it would be nice to know if switching between databases or installs will result in messages not being synced

unless the answer is too complex

what databases?

any that are relevant

like messages, specifically

i dont get it, there is one database, where do you want to switch to

the old layout had multiple, like logs.db, settings.sqlite, and omemo stuff

but how does "switching" work

let's say I'm switching between old gajim with old db and new gajim with new db

you cannot switch back, you can create a old db, then migrate it when switching to the new version

more disk activity is expected, as more requests are made to the database

so what more info would you hope for from a comparison

it just looks like an abnormal/unacceptable amount looking at my disk activity light, other applications never cause this much. I'm on a decent NVME drive.

again, that's not the only reason I asked about pitfalls with switching between installs/databases

you cannot switch, you can upgrade a database once

I currently have gajim-nightly deb and gajim-nightly flatpak installed at the same time

thats not switching, thats having 2 installations

yes you can run 2 installations ..

I just compared old db to new db installs. Old db, which has multiple accounts enabled and is joined to more chats, took 12 seconds to finish connecting to all chats. New db, which has one account enabled and fewer chats joined, took 42 seconds. Is this expected?

oh, and I had just run both versions seconds before so there were basically no messages to sync in both cases

i would say no its not expected, connecting also has nothing to do with the database

as we store only messages there

hm no, on mucs there is now a database access per presence

so joining MUCs is probably slower

you could try to disable _store_occupant_info() in the MUC module

> nicoco, did you push your changes? oopsie. now it's pushed ↺

lovetox pushed 1 commits to branch gajim/master cfix: Fix sending OMEMO-encrypted messages in MUCs - https://dev.gajim.org/gajim/gajim/-/commit/d0a9c6c9d9265816eb7a3a90feb90cd8d086fff8

hm i guess we could gather all presences while join, and commit them at once after join

instead of commiting each one

I assume memory consumption is a concern for a consideration like that? How do you decide on these things? Just try it and see what happens or do calculations?

I guess it's a relatively small amount of data. wait, that's all probably stored in memory anyway. ✏

yeah that would only become a problem if we are talking about a million muc users

at that point, a lot of other things would be first a problem

but would be cool if you could try to disable that method

to see if its really the problem

I'm going to try with my flatpak install

/files/lib/python3.11/site-packages/nbxmpp/modules/muc/muc.py ? ✏

Is there some way to disconnect and reconnect to a MUC without closing it?

lovetox: do I just comment the line that is `self._store_occupant_info(room, properties)` in muc.py? ✏

yes

MarsIronPI, no

why you dont want to close it?

because then I'd have to reopen it

it just feels like there should be a "reconnect" button ✏

ok so you are saying its disconnected?

that should not happen

it looks like it reconnected by itself now

so never mind, I guess

if gajim can show you a reconnect button, it can also itself simply reconnect and dont show you a button

yeah

lovetox: casual measurements from launch to all chats connected: old gajim database: ~12 seconds new gajim database: 42-43 seconds new gajim database with _store_occupant_info commented: 16-19 seconds Also, with that commented there is a tiny fraction of disk activity compared to _store_occupant_info enabled. This seems like disk activity is the bottleneck.

again, I have a nvme drive so this must be a lot of disk activity

not that code should be expected to not work right on a spinning disk, in my opinion

again, there are more chats joined on the old database install, so this isn't even an apples to apples comparison

is it committing once per presence?

thanks for testing, i will see how we can optimize that method

> is it committing once per presence? yes ↺

cool, happy to help

haha

it could also be a problem with indexes

i have to look into it

but yeah multiple thousand commits in a few seconds could be too much

please don't killl my flash storage :(

I'm not even using an irc bridge at the moment. I can't imagine how bad it would be in that case where I'm joined to chats that have more than 1000 occupants.

fjklp, heh I'm joined to several large channels on Libera

I feel like Converse.js doesn't handle it well

are you using gajim-nightly for that?

I'll probably test it

fjklp, I'm using a fork that adds DTLS-SRTP

But it was working fine on the version in Gentoo as well

And I'm only on a Core 2 Duo

> fjklp, I'm using a fork that adds DTLS-SRTP which one? and is it working well?

I haven't tested calls. It's the old one that still uses farstream and gstreamer

I also have the forked versions of those ✏

lovetox, how does Gajim detect disconnects if it doesn't support MUC ping?

it doesnt

MUC ping is for a very rare problem

its when the server shutsdown, and does not tell us

> its when the server shutsdown, and does not tell us Oh. I thought it was for casual disconnects that could happen semi-randomly

> it doesnt then how does it know if it's connected?

it simply assumes it until it gets other information

OK