this post was submitted on 22 May 2024
1 points (100.0% liked)

XMPP

316 readers
1 users here now

XMPP (aka Jabber) is the community-owned standard for real-time federated messaging.

For a quick start click here

JoinJabber.org support chat

JoinJabber.org admin support chat

XMPP.net Provider List

Also see JoinJabber.org FAQ

founded 1 year ago
MODERATORS
 

“Profanity” is an XMPP app. (For those who got the wrong idea about the title)

What I use:

  • Debian with Profanity (preferred for the proper keyboard and TUI)
  • Android with Snikket

What my low-tech comrades use:

  • iOS with Snikket

It’s a bit of a disaster. One iOS-Snikket user gets my msgs but never a notification. Another iOS-Snikket user is plagued with that error msg (some bogus msg about OMEMO being unsupported). My comrades are at the edge of sanity since I’m the one who imposed xmpp+omemo on them, and they have little tolerance for all the problems.

I’m not sure what to try next. I would hate to replace Profanity because it’s the only decent text based option with official debian support. Would it help if the iOS users switch from Snikket to Monocles?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 5 months ago* (last edited 5 months ago) (6 children)

The server is snikket.chat.

I am not sure what causes the OMEMO error though as I am not a iOS user.

I believe Profanity is mostly to blame for those errors. Profanity loses track of keys and fingerprints of other users, and I think what it does is encrypts the msg to myself, then transmits it without encrypting to the recipient. Then the recipient gets a msg that’s encrypted to others but they cannot decrypt it. Then to worsen matters it seems XMPP uses the same incorrect error message for many different situations. Profanity really needs to change so if any of the recipients keys are not found, it should refuse to send the msg. I see a bogus error on my end as well, and the fix is to disable OMEMO the re-enable it (/OMEMO end; /OMEMO start).

In any case, thanks for the suggestion. I’ll see if I can get someone to try that app. I cannot be fussy about features. I really just need text msgs to work.

[–] [email protected] 0 points 5 months ago (2 children)

What process did you follow to add keys on profanity? I remember it being a little confusing the first time I tried.

[–] [email protected] 0 points 5 months ago* (last edited 5 months ago) (1 children)

You question forced me to revisit this and take a closer look. I have in my notes “If someone’s fingerprint is untrusted, they will get an encrypted msg that they cannot read.” So I entered a 1:1 window with the one person who only ever gets errors from me, entered /omemo fingerprint, and it simply showed the person’s fingerprint. Then I did the same for someone who has fewer issues with me, and printed next to their fingerprint is “(trusted)”. Ah ha! The other acct has an untrusted fingerprint and Profanity does a shitty job of informing the user. The absense of a “(trusted)” when asking for the fingerprint is the crucial indicator.

To answer your question, I think keys are managed automatically. I never had to add a key. But I have had to trust fingerprints. In the new version of profanity it’s possible to enter /omemo trustmode blind. That would also solve my problem but I don’t want to be sloppy. So I have to guide the other user to their own fingerprint and confirm it.

(edit)
Well this is bizarre. There are a couple people who I can talk to in Profanity just fine with OMEMO enabled, and their fingerprint also lacks the “(trusted)” next to it. Yet my trustmode is “manual”.

[–] [email protected] 0 points 5 months ago

One other thought. I was under the (possibly faulty) impression that the first login of a snikket client helps the omemo process. Have you logged in with the mobile client yet?

I've had mixed results with omemo shenanigans on snikket iOS. Not sure how well PWAs work on iOS, but I considered encouraging my users to try one over the native client.

load more comments (3 replies)