|
1 | 1 | Random notes from Matthew on the two possible approaches for warning users about unexpected
|
2 | 2 | unverified devices popping up in their rooms....
|
3 | 3 |
|
4 |
| -Original idea... |
5 |
| -================ |
| 4 | +# Original idea... |
6 | 5 |
|
7 | 6 | Warn when an existing user adds an unknown device to a room.
|
8 | 7 |
|
9 | 8 | Warn when a user joins the room with unverified or unknown devices.
|
10 | 9 |
|
11 | 10 | Warn when you initial sync if the room has any unverified devices in it.
|
12 |
| - ^ this is good enough if we're doing local storage. |
13 |
| - OR, better: |
| 11 | +^ this is good enough if we're doing local storage. |
| 12 | +OR, better: |
14 | 13 | Warn when you initial sync if the room has any new undefined devices since you were last there.
|
15 |
| - => This means persisting the rooms that devices are in, across initial syncs. |
| 14 | +=> This means persisting the rooms that devices are in, across initial syncs. |
16 | 15 |
|
17 |
| - |
18 |
| -Updated idea... |
19 |
| -=============== |
| 16 | +# Updated idea... |
20 | 17 |
|
21 | 18 | Warn when the user tries to send a message:
|
22 |
| - - If the room has unverified devices which the user has not yet been told about in the context of this room |
23 |
| - ...or in the context of this user? currently all verification is per-user, not per-room. |
| 19 | + |
| 20 | +- If the room has unverified devices which the user has not yet been told about in the context of this room |
| 21 | + ...or in the context of this user? currently all verification is per-user, not per-room. |
24 | 22 | ...this should be good enough.
|
25 | 23 |
|
26 |
| - - so track whether we have warned the user or not about unverified devices - blocked, unverified, verified, unverified_warned. |
| 24 | +- so track whether we have warned the user or not about unverified devices - blocked, unverified, verified, unverified_warned. |
27 | 25 | throw an error when trying to encrypt if there are pure unverified devices there
|
28 | 26 | app will have to search for the devices which are pure unverified to warn about them - have to do this from MembersList anyway?
|
29 |
| - - or megolm could warn which devices are causing the problems. |
| 27 | + - or megolm could warn which devices are causing the problems. |
30 | 28 |
|
31 |
| -Why do we wait to establish outbound sessions? It just makes a horrible pause when we first try to send a message... but could otherwise unnecessarily consume resources? |
| 29 | +Why do we wait to establish outbound sessions? It just makes a horrible pause when we first try to send a message... but could otherwise unnecessarily consume resources? |
0 commit comments