In our analytics data (in Posthog), we want to be able to distinguish UTD events based on the client and version of the sender of the event (because often the problem is on the sender side rather than the recipient). The problem is that currently, we don't know this information.
It is proposed to resolve this as follows:
Include information on client information in the device keys that are uploaded via /keys/upload and then downloaded via /keys/query.
When we receive an undecryptable room message, locate the sending device via the sender_key (or device_id) embedded in the message, so that we can include the client metadata in the Posthog event.
Potential issue: sender_key and device_id are both deprecated. But they are still there today, so probably good enough for our purposes?
We will need to re-upload the device keys each time the client is upgraded to ensure the version is maintained. (This of course leads to races where, by the time a message is received, the sender has upgraded to a different client version. Hopefully that won't happen often enough to significantly impact the data.)
Consider whether we should only expose this information for people who have opted into analytics. Or some other control. It does expose the client information to anyone on the internet who cares to ask, which could be seen as something of a privacy leak.
In our analytics data (in Posthog), we want to be able to distinguish UTD events based on the client and version of the sender of the event (because often the problem is on the sender side rather than the recipient). The problem is that currently, we don't know this information.
It is proposed to resolve this as follows:
/keys/uploadand then downloaded via/keys/query.sender_key(ordevice_id) embedded in the message, so that we can include the client metadata in the Posthog event.Potential issue:
sender_keyanddevice_idare both deprecated. But they are still there today, so probably good enough for our purposes?Notes: