Design issue(?): messages can roll back delivered status if atleast one relay does not receive it

[fluoriteByte]

this is a design flaw that i kind of uncovered after messing around with my own relay, my account currently has 5 relays, 6 before i removed my own,

a message i delivered with the sender relay (which is known good) will be received by my friend, but if my slow and misconfigured relay (either accidentally or on purpose (not in this case)) doesn't know that the message was delivered or thinks it wasn't, the delivery status rolledback in real time

i couldn't take a video of it happening but here are some screenshots of me and my friend freaking out about it before i realized what caused it

bug first noticed by a friend on their end

then my end

me saying i removed my relay

it actually says delivered and doesnt act like the message undelivered

Solution:
I think that chatmail should not prioritise a relay saying a message was undelivered when many other relay did say it was delivered

[iequidoo]

This is easy to fix for 1:1 chats if MDNs (read receipts) are enabled (which is by default), see #8289 . But if MDNs are disabled and e.g. the user has 5 relays (this is the limit AFAIR; not sure how 6 could even be configured), and one of them replied with an NDN, there may be smth wrong with the message itself, so probably we still should display the message as failed.

For group chats the problem is even more complex, but it already existed before multi-relay.

[fluoriteByte]

the user has 5 relays (this is the limit AFAIR; not sure how 6 could even be configured)

probably misremembered that detail lol