MSC2845: Phone number lookups using third party API #2845
Conversation
| @@ -0,0 +1,88 @@ | |||
| # MSC2845: Thirdparty Lookup API for Telephone Numbers | |||
There was a problem hiding this comment.
This lgtm - i'm well up for (finally) using the /thirdparty/user/{protocol} API and generally improving our bridge user/room discovery UX than creating some phone-specific thing.
Co-authored-by: Hubert Chathi <[email protected]>
Co-authored-by: Matthew Hodgson <[email protected]>
| entered by the user (as defined for phone number identifiers elsewhere in the | ||
| Matrix spec). |
| Protocols are currently not namespaced and it is up to the Homeserver admin to | ||
| avoid collisions within the configuration. Any further protocols defined by the | ||
| specification should be namespaced, but collision avoidance remains the | ||
| responsibility of the Homeserver admin. |
There was a problem hiding this comment.
we might want to consider saying "unspecified identifiers should follow MSC2758" just to cover future cases, and to help steer the problem towards modern spec practices.
|
|
||
| ## Proposal | ||
| The Matrix API defines the thirdparty lookup API for this purpose: the | ||
| `GET /_matrix/client/r0/thirdparty/user/{protocol}` endpoint would be |
| ``` | ||
| [ | ||
| { | ||
| "userid": "@_sip_01818118181%40sip.example.org:example.org", |
There was a problem hiding this comment.
should we fix the naming of this while we're here? If no clients implement it, I'd consider it safe to do.
| allow much less flexibility on how a Matrix ID was formed given a phone number. | ||
|
|
||
| ## Security considerations | ||
| None known. |
There was a problem hiding this comment.
There are security considerations to be had:
- Do we need a rate limit? (yes - the spec doesn't define one)
- Is there a risk of data harvesting to pick out valid/registered phone numbers?
- etc
| The bridge is not expected to perform any canonicalisation of phone numbers at | ||
| this point: if a user dials a local number, a Matrix User ID representing that | ||
| local number should be returned. For this reason, there is no 'country' field | ||
| (or any other fields to indicate the user's location). |
There was a problem hiding this comment.
What is the expected behaviour if the client provides a local number? Is resolved relative to where-ever the bridge happens to be? To where the client is? Some other value? What if the bridge moves? What if the bridge doesn't support local numbers?
It seems like for least surprise we should require an "absolute" number here. That way the returned matrix ID can represent that number no matter what bridge is serving it and what that bridge defines "local" as.
If this isn't the case it would be nice to provide some justification.
A proposal for using the existing
thirdpartyAPI to look up bridged users for phone numbers.Rendered