|
|
@ -6,8 +6,10 @@ do so, this proposal suggests implementing an appservice extension to the
|
|
|
|
[`POST /login` endpoint](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-login).
|
|
|
|
[`POST /login` endpoint](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-login).
|
|
|
|
|
|
|
|
|
|
|
|
Appservice users do not usually need to login as they do not need their own access token, and do not
|
|
|
|
Appservice users do not usually need to login as they do not need their own access token, and do not
|
|
|
|
traditionally need a "device". However E2E encryption demands that all users in a room have a device
|
|
|
|
traditionally need a "device". However, E2E encryption demands that at least one user in a room has a Matrix device
|
|
|
|
which means bridge users need to be able to generate a device on demand.
|
|
|
|
which means bridge users need to be able to generate a device on demand. In the past, bridge developers
|
|
|
|
|
|
|
|
have used the bridge bot's device for all bridge users in the room, but this causes problems should the bridge
|
|
|
|
|
|
|
|
wish to only join ghosts to a room (e.g. for DMs).
|
|
|
|
|
|
|
|
|
|
|
|
## Proposal
|
|
|
|
## Proposal
|
|
|
|
|
|
|
|
|
|
|
|