Send IS for adding MSISDNs only when required by HS

[jryans]

A few MSISDN items are unclear in the privacy sprint:

• What is the fate of registration with MSISDN?
• If we use the IS to add MSISDNs to your account, does it mean the HS must preserve the trusted list of allowed ISes?

[jryans]

From the privacy sync:

• Investigate usage metrics
• Consider fallback options

[ara4n]

unsure why this is still blocked - afaik the conclusions from last week were that the fate of registration by MSISDN is a) we support it you fall back to v1, b) we don't implement it on the HS for now, c) in future, we will provide a HS module to let users do it if they want to foot the bill?

[dbkr]

Conclusion from IRL with Tom is that we should update synapse similar to how we did email, in that we make it use an IS of its own choosing for sending SMS, then add a corresponding flag in /versions to tell the client it can request sms tokens without supplying an ID server.

[dbkr]

Filed matrix-org/synapse#5929 to track synapse changes. On the riot-web side, we just need to honour the same flag for the msisdn adding stuff.

[jryans]

Thanks all, looks like we have a clear plan. I morphed this issue to do the Riot Web work of checking the flag. We should coordinate with Synapse side to decide if we're reusing the same flag from email, or something new for MSISDNs.

[jryans]

I believe @turt2live is a writing a (previously missing) MSC around the email and MSISDNs changes, which may incidentally describe whatever flags have been agreed.

[jryans]

MSC2263 records that m.require_identity_server will return a boolean that applies to both email and MSISDN cases.

[turt2live]

If we use the IS to add MSISDNs to your account, does it mean the HS must preserve the trusted list of allowed ISes?

I think this question is still unanswered, or if it is answered I'm failing to interpret it. Either way, it's a good thing for a different issue, I think?

[jryans]

If we use the IS to add MSISDNs to your account, does it mean the HS must preserve the trusted list of allowed ISes?

I think this question is still unanswered, or if it is answered I'm failing to interpret it. Either way, it's a good thing for a different issue, I think?

I was assuming Tom and Dave worked out that we don't need the trusted list, since they agreed to proceed in the same way we did for email handling. @lampholder, can you confirm?