Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-02 17:54:09 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

words

Browse source
This commit is contained in:
Will Hunt 2021-05-05 23:14:48 +01:00 committed by GitHub
parent c8e0ed6062
commit 93dd264c30
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
proposals/2778-appservice-login.md
View file

@ -6,14 +6,14 @@ 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 at least one user in a room has a Matrix device traditionally need a "device". However, E2E encryption demands that at least one user in a room has a
which means bridge users need to be able to generate a device on demand. In the past, bridge developers Matrix device which means bridge users need to be able to generate a device on demand. In the past,
have used the bridge bot's device for all bridge users in the room, but this causes problems should the bridge bridge developers have used the bridge bot's device for all bridge users in the room, but this causes
wish to only join ghosts to a room (e.g. for DMs). problems should the bridge wish to only join ghosts to a room (e.g. for DMs).
Another advantage this provides is that an appservice can now be used to generate access tokens for Another advantage this provides is that an appservice can now be used to generate access tokens for
any user in its namespace without having to set a password for that user, which may be useful in the any user in its namespace without having to set a password for that user, which may be useful where
case of software where maintaining password(s) in the configuration is undesirable. maintaining password(s) in the configuration is undesirable.
## Proposal ## Proposal