Messages bluntly refuse to send in a room with an unverified device present.

[ara4n]

Steps to reproduce

1. Upgrade to build 706
2. Try to speak in a room where a verified user has an unverified device present (i.e. red shield on EW)
3. Message fails to send outright, without any retry button
4. "Sending failed [OK]" is the dialog if you tap the (!) icon.
5. On removing the errant devices, messages then send okay.

Outcome

What did you expect?

An error message which actually explains what the problem is and how to fix it. From memory, the intended behaviour is to warn the sender loudly about the unverified device, but not block sending outright?

Also, if a message send does fail like this, i'd expect to be able to resend it - rather than have to copy the body and paste into the composer and hit send again, which just ends up with stacks of unsendable msgs.

What happened instead?

Cryptic failure with super-frustrating lack of retry button.

Your phone model

No response

Operating system version

No response

Application version

706

Homeserver

No response

Will you send logs?

Yes

[mxandreas]

Overall, this is by design. It is a stop-gap solution in a sense that eventually users won't see it because all of their devices are verified or if they are not, then those devices are excluded. Also, it was meant to apply only when you have explicitly verified the user with such devices - meaning it concerns a small percentage of current users who are very "strict".

Now, what is new and was realized yesterday, is that each person counts as a verified used to themselves. From a security perspective that makes sense - as otherwise a malicious homeserver could add a device on behalf of you and you would not notice. However, it was not considered when thinking about the overall current UX.

[BillCarsonFr]

Maybe instance of matrix-org/matrix-rust-sdk#3973

[mxandreas]

Also, if a message send does fail like this, i'd expect to be able to resend it - rather than have to copy the body and paste into the composer and hit send again, which just ends up with stacks of unsendable msgs.

You can click on "Send anyway" for that.

[pmaier1]

Message fails to send outright, without any retry button

Did you see a red indicator on the message? Tapping it should give you the ability to resend. Or did you not see that at all?

[mxandreas]

For reference / visibility - here is the ticket to adjust the copy, in case this was your own device: element-hq/element-meta#2534

[ara4n]

Did you see a red indicator on the message?

Yes

Tapping it should give you the ability to resend.

No. It popped up a "Send failed [OK]" alert, and nothing else.

[ara4n]

it looked like this:

[ara4n]

For reference / visibility - here is the ticket to adjust the copy, in case this was your own device: element-hq/element-meta#2534

It wasn't my own device. The repro steps were:

• Be logged in as yourself (@matthew:matrix.org in this instance)
• Verify a user (@matthewtest:matrix.org in this instance)
• Log into that account on an unverified device (iamb or something, in my instance)
• Discover you can no longer send msgs in any room where @matthewtest:matrix.org is present, with the "Sending failed" failure mode.

[mxandreas]

It wasn't my own device.

Got it, was just putting it here for visibility when it comes up with your own device.

The repro steps were.

FWIW - tried this morning myself and it worked as expected, if it helps with anything.

[pmaier1]

FWIW, ignore #3287 (comment). This was in the context of https://github.com/element-hq/crypto-internal/issues/370.

[ara4n]

(see also #3354, which is specifically for verified users with unverified devices)

[BillCarsonFr]

Looks like it is related to that matrix-org/matrix-rust-sdk#3973 but not exactly the same?

[BillCarsonFr]

Maybe instance of matrix-org/matrix-rust-sdk#3973

So I might be repeating myself :/

Anyhow it is possible that we have an occurence of the #3973 bug, while at the same time a timeline reset is happening (because of a gappy sync?)