An idea we had to help us fix UTDs was to provide a button next to the "Unable to decrypt message" error which would open the rageshake dialog. The idea is that it:
could provide better quality data than the existing auto-rageshake functionality, which can be a bit noisy (and is too high volume to process sensibly)
is likely to attact a more representative cross-section of users than the auto-rageshake functionality (which is a labs option you have to opt into)
is more likely to be used than a manual rageshake
can include more data than a manual rageshake (eg, ID of affected event) and also trigger a rageshake from the sender side.
To make it properly useful, once the rageshake is submitted, we should send the sender a to-device message about it. The sending user would see a dialog like the one Element Call has ("Someone had an error! Would you like to send logs to help us debug?") prompting them to also send a rageshake.
An idea we had to help us fix UTDs was to provide a button next to the "Unable to decrypt message" error which would open the rageshake dialog. The idea is that it:
To make it properly useful, once the rageshake is submitted, we should send the sender a to-device message about it. The sending user would see a dialog like the one Element Call has ("Someone had an error! Would you like to send logs to help us debug?") prompting them to also send a rageshake.