Fix detection of encryption for all users in a room

[weeman1337]

fixes element-hq/element-web#24995

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

element-web notes: When starting a DM, it is now ensured that the message can be encrypted for all users before encrypting the room.

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Fix detection of encryption for all users in a room (#10487). Fixes DMs are always created as encrypted even when the other device doesn't support encryption element-hq/element-web#24995.

[richvdh]

s/devices/users/.

I think this is a change of behaviour from before 3.69.0. Are we sure it's what's expected?

It's also inconsistent with the documentation on the function. If there are no users in the room (or rather, in the userIds list) then "there is at least one device that we can encrypt to" is trivially true.

[richvdh]

It's also inconsistent with the documentation on the function. If there are no users in the room (or rather, in the userIds list) then "there is at least one device that we can encrypt to" is trivially true.

sorry, I misquoted.

If there are no users, then "for every user in a room, <X>" is trivially true, for any <X>.

[weeman1337]

Yes, this is a change. Not sure if it is correct. If I download the keys for a list of users and I do get an empty response, can I not encrypt to them? 🤔

An empty userIds arg is a slightly separate case. If I do not specify a user, I cannot encrypt to them.

[andybalaam]

If a user has no devices, I don't think I want that to make me stop sending to a whole list of users. I can trivially do the right thing for that user, which is nothing.

Happy to be persuaded though.

[richvdh]

An empty userIds arg is a slightly separate case. If I do not specify a user, I cannot encrypt to them.

worth noting that downloadKeys is not a direct map to /keys/query. As things currently stand, downloadKeys will return an entry in the map for each user in the input - even if they have no devices (in which case the device map for that user will be empty).

So no, it's not a separate case: the question is entirely about the behaviour of the function when the userIds arg is empty.

Honestly, I think the actual behaviour here is pretty unimportant, provided the documentation matches. Personally, I would have gone for preserving the previous behaviour, but if you want to change it, that's ok, but please update the docs.

[weeman1337]

@andybalaam do you mean a misc case here where some users have devices?

To clarify about the discussion from above:

• Before: 0 users or 0 devices returned by downloadKeys → true
• Now: false

[weeman1337]

element-hq/element-web#24998

[richvdh]

If a user has no devices, I don't think I want that to make me stop sending to a whole list of users. I can trivially do the right thing for that user, which is nothing.

First of all, let's clarify. This code is relying on downloadKeys only returning devices which have encryption keys. So we're talking about encryption-capable devices here.

The whole point of this function is to check that all users in a given list have at least one encryption-capable device - which means we can safely encrypt a room which contains those users.

So, I disagree with you here @andybalaam: if any one of the users in the list has no (encryption-capable) devices, I do not want to start an encrypted room with the whole list.

[andybalaam]

What Rich said makes perfect sense to me.

[richvdh]

A comment would be useful here:

Suggested change

	return false;
	// this user does not have any encryption-capable devices.
	return false;