Conversations: [UI] The OMEMO-Dead-end: Improve trusting popup screen

[Echolon]

Introduction

Since I'm using Conversations and that I invited most of my personal contacts to XMPP, I experience that they often get stucked, if this special screen below pops up AND prevents them from chating if there are any key-exchange problems in MUCs.

_Sorry, it is in German, it basically says that there is no usable key available and a server issue_

This is a big dead-end as I think. Often enough - because my server was shitty - but still, lots of people e.g. from ChatSecure, just register and run _home.zom_ or other servers which don't support all XEPs or features. And this is a problem of consistency IMHO. This why I would like to suggest the following changes.

Current situation

There are basically two situations (as I experienced):

• The "DONE"-case: All keys are getting exchanged and blindly trusted. Everything fine - Click & Done.
  However, this screen pops up, but most users have no idea why and what it means. Furthermore, for every contact the same message is repeated again and again _(but acutally has no real meaning to the user)_.

• The "Dead-end"-case: If just one user fails, for whatever reason, most people get caged. They still don't know what the screen is for, they don't know what is happening and they finally wonder why they cannot write. And that because they don't know that this is about OMEMO, that they need to deactivate encryption and even so not know how to deactivate. So, as said I usually see them stucked in this dead-end and they start texting me in the single chat, asking why they cannot chat...

Suggestions about what could be improved

I think the following things could be done about both situations:

• Collect the cases: If there are more than 3-4 people in a room, this screens gets a bit overloaded. So all working IDs should be collected, and then on final text message about trusting should be shown.

• Give visual feedback: Every trusted contact _(IMHO even if blindly trusted)_ should get a green tick ✔. Okay, maybe a yellow one for BTBV and a green one for verifyed contacts. All non working cases should get a red cross ✖. Now, if the user sees the popup screen, they immediately see that things work out or not. The screen before didn't really show directly with whom things are working or not.

• Let 'em chat: If there are any encryption issues, just let them pass (automatically) with a note that they are writing unencrypted. I think this app is about communication in the first place. Additionally, others can help and recognise that they couldn't write at all before.

I see my title is a bit subjective, so feel free to change^^.
Feel free to add your comments.

Cheers & thanks for the app!

[licaon-kter]

/duplicate https://github.com/siacs/Conversations/issues/3081 when you talk about MUCs

In 1:1 you can switch to unencrypted.

Not sure Conversations should just change and accept to "disable everything" for shitty servers.

[Echolon]

Yes I saw this, still wasn't sure if this is a new one worth. If you want me to drop the suggestions there, I can do it.

Yes I am talking about MUCs. And I think the switch to unencrypted should happen automatically.

[licaon-kter]

Still imho a duplicate.

Yes I am talking about MUCs. And I think the switch to unencrypted should happen automatically.

So my group of 10, OMEMO for months, I add another contact that just went offline for the day... and your idea is to switch us all to unencrypted? O RLY?

How about no...

From #3081

Gajim behaves more gracefully in this case and sends OMEMO-protected messages. The newly added user won't be able to decrypt them of course but at least that is more secure than forcing other users to send unprotected messages.

This +1

[iNPUTmice]

The important question is - before we figure out how to work around it -
what caused it? Do this Jids not exists? Have they never logged in before
and never published key material? Is the server broken and forgets key
material. Without knowing that it's pointless to come up with some half
assed workaround to either not send the message to those contacts or to
disable encryption. If we just not encrypt to those contacts we will just
run into the next problem of those contacts not being able to read the
message. Which is what happens when you use Gajim. That's not solving the
issue that's ignoring it.

[Echolon]

@licaon-kter: Buddy, my issue is not about dropping encryption for everyone. It's rather about stateing that the current way isn't helpful either and discuss possibilities. Why are you always so rude for no reasons...? If you see it as duplicate, just close it...

@iNPUTmice: Of course, I see that this is no a direct way of solving the issues. But I think leaving people stucked in this screen and preventing them from chatting or telling that they have issues doesn't help either. Sure, if Conversations can determine a reason, it should be named. But the current screen doesn't divide into "working" and "non-working" IDs. Maybe at least this should be improved as suggested.

If we just not encrypt to those contacts we will just
run into the next problem of those contacts not being able to read the
message.

It means that all contacts get encrypted messages and the "broken" ID, too. But its client will ignore it? Sure, thats not a solution.
But I disagree, that my suggestion is fully ignoring it. At least it gives feedbacl and lets the user decide.

I mean, we have the following situation: We create a MUC, people join, at least one doesn't work. So far I had to deactivate encryption for the chat. Why? Because I'm not going to exclude the person. I think most people would react the same way. True - if there is a direct threat or need for encryption, people should fix the problem. But still, the current solution is to write unencrypted. Or what do you suggest, expect of forcing people to change their client/server?

I see that my suggestions are not appropiate in terms of solving the problem. but I think they reduce the "dead-end" situation and give some help for the user that something is not working with someone specific at all. As Conversations app couldn't solve issues for others of course and we probably won't reach this point at all, I still suggest to implement the stuff, expect of the controversial decrypt setting I named.

Cheers

[Echolon]

I have a non-anonymous group of like 15 friends. CS users, too. Sometime I dont see people for weeks. Then we meet and they tell me that they weren't able to write me :/. Like yesterday

However, in this case there was an engineer(!) telling me he just dont understands it, maybe he is just stupid. Of course he is not.

I think for group chats, thats obviously 90% where the dead-end comes up, at least the first two suggestions + an advise to deactivate would already help significantly. Maybe even a small icon of the locker could visually give them a hint where they have to go.

In another issue #3195 I also suggested to rename the choices from e.g. 'OMEMO to 'Encrypt (OMEMO)'
so people directly knows whats it for.

[licaon-kter]

my issue is not about dropping encryption for everyone

That's ok, yes, they could write unencrypted

Sometime I dont see people for weeks. Then we meet and they tell me that they weren't able to write me :/.

Wasn't the OP issue about new members of the MUC, you have issues with existing users too? Did they change devices? Clients? Delete their keys?

Why are you always so rude for no reasons...?

Why did you assume my tone?

If you see it as duplicate, just close it...

I'm not the dev

[Echolon]

My point is rather, that I never know if something is working or not. Because they are "sliently" stucked on their side. Could happen at the time when some joins a chat. Could happen later on too for different reasons... :(

Perhaps, we need to confess for the moment, that being consequent about _"Let's rather find out what it is"_ just worsen the problem. At least if they stay silent. For sure, I know it's often enough shitty configuration or iPhone users and not Conversations fault or responsibilty. However, one can say good treatment of such suitations is postive for image of an app, too. And that won't be the last time we have to deal with such things in an heterogenous network like XMPP. Just my 2ct

[canary5]

Hello, i will comment this too. Happens for me many times too, when adding new contacts. They have published keys, not new, those keys work with others, etc
Sometimes this errors and on 'good' servers. What i do. If i cant write, then i ask other side to msg first. Replying the problem gone. And sometimes people call me to write first...
If you dont have other communications you lost...
It happening many versions, more then year for sure

[Echolon]

@canary5 I think this is the top 1 frustrating thing for (my) new xmpp-friends. This must be somehow handled. Furthermore, they always relate this to the app, because they dont understand whats happening and even more that the app is acutally not responsible usually. So shitty clients/servers make it worse for all others. I think we cannot wait until those are fixed (or people learn hpw to encrypt/xmpp^^)

[Echolon]

Another thought I had: Let's say the user gets stucked in this dead-end. Then there could be an option which will allow the user to directly 1:1 chat to the owner or a dedicaded JID + shortend output of the issue to the 1:1 chat. So, the user can explain and even mention that something is not working.

Yes, I see that this is a weird work around and not directly solving, but just adding this thought. Maybe someone else has an improved idea...

[iNPUTmice]

Since this thread is moving nowhere to actually discover anything about the underlying problems and is just about providing a work around I’m closing this as duplicate of #3081.