Gajim - 2024-05-20

hi @everyone.. I dont remember did anyone replied to this, but don't you think that OMEMO fingerprints are ugly and in case of your contact has 10 devices, it is almost impossible to identify them correctly? is it theoretically possible to generate vanity keypairs that represents first 3-5 characters of device name? for example LAPT1, LAPT2, PHON1, PHON2 etc, of course converted from hex

it seems like gajim startup time get speed up even more

ann, i dont understand what you are trying to do, what does it mean to identify someone correctly?

lovetox: I see that db migration for reactions has been added, is it a good time to test it out and break it? :)

you can use this branch, its 99%

also as it adds only one new table, its backwards compatibel if you want to switch back

ann: > hi @everyone.. I dont remember did anyone replied to this, but don't you think that OMEMO fingerprints are ugly and in case of your contact has 10 devices, it is almost impossible to identify them correctly? > > is it theoretically possible to generate vanity keypairs that represents first 3-5 characters of device name? for example LAPT1, LAPT2, PHON1, PHON2 etc, of course converted from hex Telegram represents fingerprints as short emoji sequences (since there are a lot of emojis)

Xmpp clients could do that for omemo fingerprints

in what situation does this help? Are you saying you meet people in person and compare fingerprints, and have a hard time finding the right one?

I guess that is what you're supposed to do more or less, otherwise the e2e is pointless as it can be mitmed by the server. I mean you're supposed to verify them somehow

I have two schizo friends that insisted on me taking a pic of my omemo fingerprints lmao

im not saying you should not verify fingerprints, im just trying to understand what task it is the ann has a problem with. for example if its not the in person situation, it could be more useful to add a search field for a fingerprint, because you copy paste it from an out of band channel. ✏

I forced my friend to print his omemo, lay a signature on it and make a picture with this piece of paper and his face

emojis have the problem that they are dependend on the font you use, the same emoji looks different if you use a Mac, a Windows machine, or a linux machine with google noto installed

They always look the same on telegram, but telegram ships its own fonts instead of depending on a libraries of random distro-supplied versions

But also while emojis look different they're supposed to be same in their meaning. Like a 🐷 will still be a pig on any platform capable of displaying it all

Telegram does emojis for calls, so you can verbally describe what you see

❤️♥️

you would describe this as read heart i guess

of course one could try to remove emojis that look a like from the algorithmus

Hehe

> you can use this branch, its 99% and now hell has broken loose :) ↺

why?

> why? Reactions popping everywhere 😲😁💪👍

lovetox pushed 1 commits to branch gajim/master cfix: Deduplicate PMs correctly - https://dev.gajim.org/gajim/gajim/-/commit/8ba0c95fdf2e545c94d0bd134f921eec81ff7f23

I'm trying the current master of python-nbxmpp and gajim, but migration fails:

``` https://conference.gajim.org:5281/pastebin/e8f5e18c-973d-4a46-8615-da9744e3bb63

Any idea what is going wrong?

hm something with the jid validation

let me quickly take a look should not be hard to solve

hm not sure how this is possible, you seem to have a jid #test:matrix.org@... in your archive

but ":" is not allowed in jids

Maybe I can find and remove it. It's probably a leftover from some experiments with slidge-matridge.

lovetox pushed 1 commits to branch gajim/master cfix: Migration: Don’t fail on invalid remote JID - https://dev.gajim.org/gajim/gajim/-/commit/814e0d0b5615830e699d92b0d5a42b76e7987c10

debacle, update git, and try again

lovetox, will do!

you may have to restore your database, it was backuped with .bkp suffix

lovetox, no: a diff with my backup shows no difference, neither new nor changed files ✏

lovetox pushed 1 commits to branch gajim/master feat: Add XEP-0444: Message Reactions - https://dev.gajim.org/gajim/gajim/-/commit/269d436cc10185756929250d37b803140010d88a

🥳🎉

oh man, it's happening

is there any place that describes the purpose of each gajim project file? I'm guessing the answer is "learn to code"/ ✏

fjklp: what's a project file?

is there any place that describes the purpose of each gajim project file? I'm guessing the answer is "learn to code". ✏

python files, gajim itself ✏

mostly the name of the file itself and the path

sometimes a comment is put in top

lovetox Database migration worked well now, thanks!

Oh, I actually see the reactions from Gajim in Dino. Nice!

so, what do you awesome devs have planned next on the roadmap, now that replies and reactions are shipped?

A/V calls? Threads?

making a release and fix all the bugs that people discover

Stickers! ;-)

this feels like a big release for gajim

from the user perspective

one of the low hanging features that we will probably implement next is, - message retraction - displayed markers in MUCs - more MUC moderation features - And a lot of other small things

On the long list, is probably - A/V - Better Filetransfer - OMEMO2

I find the default message highlight color to be terrible. How do you guys feel about the possibility of a different one? Or including multiple preconfigured gajim style themes? Or packaging gajim with different gtk themes?

i think its the selection color of your theme, how can it be terrible

do you have a screenshot?

this task is not as trivial as it seems

flatpak

it sure would be nice if changing gtk theme didn't require issuing commands, which requires looking up those commands, etc

maybe later

is it expected that users don't or should not alter their gtk theme to anything other than adwaita or adwaita dark?

you can do whatever you want, but if you are not happy with the colors of that theme then .. not sure what we should do

im using ubuntu and they also have their own theme, works ok in Gajim

if you discover something that does not fit in your theme, then we need to look at it, and check if we use the wrong theme constant or maybe the theme could be improved

Mention color is explicitly orange, maybe that is what you meant, fjklp ?

yes

orange highlight with light text color means no contrast

but also the animation conversation-row-highlight

has a fixed color

so thats not good then, basically the rule is we should not have fixed colors

Yes

it should always something defined by the theme in use

We can also do fancy things with css I think. Like inverting

but for what reason, highlight or selecting is a basic things in themes, and the theme designers thought about what to use here

i see no argument why we should define a single color ourself

isn't the highlight color chosen within gajim only?

> ann, i dont understand what you are trying to do, what does it mean to identify someone correctly? to identify someone's device (is he writing from the phone, or from laptop, or from desktop) in another words, to match key fingerprint with friendly device name.

lovetox: i mean to distinguish hightlight from selection from mention

And then to have variety (apart from the single "selected bg" color, use that color and play woth it dynamically for other things

Otherwise it would be all blue in adwaita

ann, OMEMO2 defines a device name per fingerprint, but in OMEMO1 we dont have this.

But your usecase sounds not really like something todo with fingerprints

do i understand you correctly, you want to know from which device a user sent a message?

devices have resource names, for example mine currently is

Gajim.xxxxx and Conversations.xxxx

Would this satisfy what you want?

but in gajim you dont see from which device you got a message, only a OMEMO fingerprint and only in case of encrypted conversation, like this

https://im.ebala.net:5821/upload/tIpUGU1j071BsIZaaazQlWcj/dbd443c7-ab88-4545-ad6d-0a9bfcb8b3f4.png

yes, thats exactly the problem, if you want to know from which device a message comes, the solution cannot be encryption, because it would only work half of the time

we currently store the device name of each message, so at least we have the info available

OMEMO2 with linked device name sounds good, but initally I mean to vanity generate of your OMEMO key in a way which first octet converted to ASCII will represent human readable string for example, if first octet will be 49 50 48 4E, we may convert it to IPHN, for example. vanity generation is: https://academy.bit2me.com/en/what-is-a-vanity-address/

but I have no idea how much resources it will cost to generate such private key

Ok but how does that help you in an unencrypted chat? ✏

> unencrypted chat > 2024

yeah but in XMPP most MUCs are unencrypted

2024 or not :)

> we currently store the device name of each message, so at least we have the info available that way, why not just show resource name when hovering mouse over nickname, as currently Gajim shows full date on hover of timestamp

the question im asking is, do you need this info in relation to encryption, or do you want the device name independent of the fact if the chat is encrypted or not

tbh both will be perfect, because resource name is not as unique as key fingerprint

its not unique, but why would you need the info if something is from a very specific device?

is the info you are after not just, is my contact on a smartphone? or on a desktop?

and for that resouce name is good enough, even if not unique

after all, yes, you are right, I'm just crypto paranoid and all chats except MUCs are encrypted and sometimes you encounter this:

https://im.ebala.net:5821/upload/92v7BLHEXdJ-1gFD8iYFScaS/8f338e66-f70e-4a7c-916f-1c4120e7b4da.png

that's why idea of even 4 human-readable bytes was came

its hell and I literally have no idea are all that devices are legitimate or not and it may be MITM (not in this case, but.)

but if you paranoid you distrust all devices simply until you exchange a fingerprint out of bound

what does it help you if the first 4 octets are letters?

you still dont know the key

i thought about adding the functionality that you can define a name per key yourself

if you see the green shield you know the message comes from a verified device

if the shield is orange, from one you didnt verify

for security reasons i think thats all that is important or?

> but if you paranoid you distrust all devices simply until you exchange a fingerprint out of bound This ^ ↺

> what does it help you if the first 4 octets are letters? it won't help with paranoia, but it would help to identify kind of device (if private key also vanity generated on other side of course)

> i thought about adding the functionality that you can define a name per key yourself That would help when you need to distrust a device in case of lost, etc?

I assume that the purpose of keys represented by emojis is that you can much more quickly read them aloud over voice communication channels as well as visually read them quicker to verify. It does seem to have benefit for that.

Do plugins, such as openpgp (OX), need a new version for the current Gajim master?

debacle, its not adapeted to the new code yet

do you actively use that?

Yes, I just got a message from a profanity user, that could not be decrypted on my side.

Up to 1.8.4 this used to worked fine.

yes we still need to adapt it to the current gajim state

> yes we still need to adapt it to the current gajim state no hurry, but it would be nice, if you can fix it before the next release (1.9.0?) ↺

btw. I like the UI for replies and reactions! Congrats!

> > what does it help you if the first 4 octets are letters? > it won't help with paranoia, but it would help to identify kind of device (if private key also vanity generated on other side of course) ann wouldn't this production of vanity keys require brute force key generation, meaning producing many keys and occupying a cpu or gpu for a long time? Is there code to do this yet? How long might it be expected to take? Alternatively, might it make more sense for keys to be kept and shared with metadata as a separate thing?

what are the storage methods are presently used for omemo keys where people fetch them from? is it presently possible to store them with metadata? ✏

maybe I'll get back to the theme stuff another day, but it should be improved, imo. I also kind of like the idea of packaging a few gtk themes with gajim. But at least, the colors in gajim should be expected to work together, imo.

debacle, i pushed a commit to the plugin repo, could you try if it works with that

> ann wouldn't this production of vanity keys require brute force key generation, meaning producing many keys and occupying a cpu or gpu for a long time? Is that's exactly what I said in previous message - I have no idea how many resources it wil take to generate such key.

debacle basic encryption with openpgp should work now, i tested it

but all the new features like reactions and replies are not working, because there are unsolved problems

imagine rewriting gajim in rust...

lol joking.

> but all the new features like reactions and replies are not working, because there are unsolved problems Thanks! As my main contact is on profanity... :-) ↺

also we have forked Conversations (say hello to their brand new material UI that eats 50% space) and named it Conversations Classic. some features have been backported from Cheogram (service discovery, dtmf dialer), some features have been implemented from scratch (XEP-0461/message replies), some core UI improvements (its not as obvious but adds some missing feature as jumping to message by its id from search or from reply) we are very open for any features requests which you always wanted to see in Conversations [Classic], but were always afraid (because of its wonderful developer, sorry inputmice) link: https://dev.narayana.im/narayana/Conversations-Classic now you have my permission to ban me for advertising but I hope not ;p ✏

full changelog and build server with signed releases coming soon our goal is to achieve something like Telegram in its best state, like year ~2018, when UI was clean and nice and UX was one of the best in messengers, but half-screen-animated excrement emojis still weren't in place ✏