Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2025-12-27 03:18:37 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

General clarity improvements

Browse source
This commit is contained in:
Travis Ralston 2019-08-16 19:59:32 -06:00
parent 22c9692684
commit 865d3da0f8
1 changed files with 15 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
proposals/1957-integrations-discovery.md
View file

@ -79,15 +79,16 @@ The user is able to have multiple integration managers through use of multiple w
#### Display order of integration managers
Clients which have support for integration managers should display at least 1 manager, but may decide
to display multiple via something like tabs. Clients must prefer to display the user's configured
Clients which have support for integration managers should display at least 1 manager, but should
display multiple via something like tabs. Clients must prefer to display the user's configured
integration managers over any defaults, and if only displaying one manager must pick the first
manager after sorting the `state_key`s in lexicographical order. Clients may additionally display
default managers if they so wish, and should preserve the order defined in the various defaults.
If the user has no configured integration managers, the client must prefer to display one or more
of the managers suggested by the homeserver over the managers recommended by the client.
manager after sorting the `state_key`s of the applicable widgets in lexicographical order. Clients
can additionally display default managers if they so wish, and should preserve the order defined in
the various defaults. If the user has no configured integration managers, the client must prefer
to display one or more of the managers suggested by the homeserver over the managers recommended
by the client.
The client may optionally support a way to entirely disable integration manager support, even if the
The client can optionally support a way to entirely disable integration manager support, even if the
user and homeserver have managers defined.
The rationale for having the client prefer to use the user's integration managers first is so that
@ -157,7 +158,10 @@ Some things which may be desirable in the future are:
## Security considerations
When displaying integration managers, clients should not trust that the input is sanitary. Integration
managers may only be at HTTP(S) endpoints and may still have malicious intent. Ensure any sandboxing
on the manager is appropriate such that it can communicate with the client, but cannot perform unauthorized
actions.
When displaying integration managers, clients should not trust that the input is sanitary. Per the
proposal above, an intergration manager is only permitted to be served from HTTP(S) URIs. A given
integration manager can still have malicious intent however, and clients should ensure any sandboxing
on the manager is appropriate such that it can communicate with the client, but cannot perform
unauthorized actions. Other URI schemes are just as dangerous and could potentially be allowed by
this proposal - use cases are less defined and desirable for schemes like `file://` and are excluded
by this proposal. They can be added in a future proposal if a use case arises.