| 11 Jan 2020 |
 tulir | and verifying them all too | 15:31:25 |
 jcgruenhage | what exactly do you have against sending EDUs to ASs? | 15:32:11 |
 Sorunome | if you have double-puppeting you can auto-verify yourself | 15:32:12 |
| jcgruenhage | * what exactly do you have against sending (ghost) EDUs to ASs? | 15:32:37 |
| tulir | In reply to @jan.christian:gruenhage.xyz
what exactly do you have against sending (ghost) EDUs to ASs? nothing, I just have everything against managing thousands of e2ee devices | 15:32:47 |
| Sorunome | you argued against receiving those of the ghosts, though | 15:33:01 |
| jcgruenhage | but you don't have to | 15:33:02 |
| jcgruenhage | just because the spec allows you to receive EDUs, doesn't mean your bridges need to support any e2ee stuff | 15:33:29 |
| tulir | In reply to @sorunome:sorunome.de
you argued against receiving those of the ghosts, though because it's not strictly needed, but either way is fine | 15:33:31 |
| tulir | In reply to @tulir:maunium.net
I guess that EDU proposal could just send the to_device stuff to all puppets to make that easier (have the bot in the namespace too) ^ | 15:33:34 |
| Sorunome | In reply to @tulir:maunium.net
because it's not strictly needed, but either way is fine it is needed if you want real DMs without an ugly AS bot sitting in them, etc. | 15:34:06 |
| Sorunome | or small group chats without a bot | 15:34:15 |
| Sorunome | like discords dm groups | 15:34:18 |
| tulir | I mean that part just makes horrible e2ee UX, but yeah whatever, I'll make my bridges use a single device | 15:35:00 |
| Sorunome | can you make different accounts use the same device 🤔 | 15:35:19 |
| Sorunome | accounts/ghosts | 15:35:32 |
| tulir | something like that will eventually be needed | 15:35:42 |
| tulir | as I mentioned in #e2e:matrix.org, you can already send stuff encrypted by another user's device, but that's somewhat of a vulnerability. As a short-term solution, that should be marked as untrusted (which doesn't prevent bridging but will make the UI less nice with warnings) and in the long term there should be some kind of device delegation for AS users to say the bot device should be trusted as if it was the AS user's device | 15:37:33 |
| Sorunome |
and in the long term there should be some kind of device delegation for AS users to say the bot device should be trusted as if it was the AS user's device
that sounds like the proper path, then. However, that also means taht the EDUs from all ghosts need to be received, to mimik the AS bot device thingy
| 15:39:03 |
| Sorunome | then the AS bot doesn't need to be in the room and the user doesn't need to trust 9001 devices | 15:40:10 |
| tulir | In reply to @sorunome:sorunome.de
and in the long term there should be some kind of device delegation for AS users to say the bot device should be trusted as if it was the AS user's device
that sounds like the proper path, then. However, that also means taht the EDUs from all ghosts need to be received, to mimik the AS bot device thingy
that depends on what the EDUs are exactly | 15:41:16 |
| tulir | like the to-device events would probably go to the bot directly even though it's only the ghosts in the room | 15:41:28 |
| jcgruenhage | but that's more special casing instead of less, what you argued against earlier? | 15:41:58 |
| tulir | it's the bot's device | 15:42:23 |
| tulir | that device delegation isn't really avoidable for a proper solution, but it doesn't need to be AS-only (e.g. might also be useful for stuff like bots hosted in the same place) | 15:43:28 |
| Sorunome | soooooo, why shouldn't all EDUs from all ghosts be received, then? | 15:44:10 |
| Sorunome | like, how does that contradict that you delegate the device to the AS bot | 15:44:26 |
| tulir | that part doesn't really matter | 15:45:12 |
| tulir | there probably won't be any e2ee edus to the ghosts, but it's not me implementing the sending part so you can do whatever | 15:46:09 |
| Sorunome | ok | 15:47:59 |
