MSC2499: Fixes for Well-known URIs

[aaronraimist]

Rendered

Intended to address:
https://github.com/matrix-org/matrix-doc/issues/1919
https://github.com/matrix-org/matrix-doc/issues/1896
https://github.com/matrix-org/matrix-doc/issues/2335

If there are any other issues with the client well-known that I've missed let me know so there doesn't need to be a followup MSC.

[KitsuneRal]

Generally ok except one small addition, please.

[KitsuneRal]

In relation to this issue, I think it's worth clarifying in the spec that as long as a fully qualified MXID is supplied and the .well-known lookup fails for whatever reason, the client MUST NOT use whichever default server it might have. IGNORE description in the spec isn't quite clear on that; actually, it almost encourages the behaviour described in the issue by saying that the client can use "default values" to fill in required parameters.

[aaronraimist]

You know what, actually reading the spec again maybe FAIL_PROMPT is the correct thing to do but Riot just isn't doing that. Riot is doing something closer to a FAIL_ERROR, rather than a FAIL_PROMPT. I'm thinking IGNORE should just be removed from the spec completely and 3a and 3b should be a FAIL_PROMPT.

[KitsuneRal]

I wouldn't be so harsh on IGNORE - it allows the user to go without an unneeded roadbump in 3a in case the client managed to get the clear message from the server that there's no .well-known support here. The IGNORE description is too affording though.

[aaronraimist]

Yeah it would be nice if there was no extra step but if using defaults values is removed from IGNORE then how will the client find out the server URL? The only way is to prompt the user unless I am missing something. So it would be the same as FAIL_PROMPT.

[KitsuneRal]

Probably the spec should be clear about the scope of cases for auto-discovery. Specifically, if the user entered a fully qualified MXID, only then auto-discovery kicks in. Using the default value in a situation when the serverpart is already provided but the server happens to have .well-known not quite ideally configured (i.e. step 3b) is definitely the wrong way out. Asking the user to confirm that the server is correct because auto-discovery fell short is the right way but both IGNORE and FAIL_PROMPT speak about that anyway.

[turt2live]

FAIL_PROMPT is probably still correct, I think. Element (then Riot) likely has a bug in this area, though its UX doesn't really lend itself to "prompting" the user. It should probably offer the ability to continue anyways, though.

[aaronraimist]

Yeah I'll take this out.

[turt2live]

FAIL_PROMPT is probably still correct, I think. Element (then Riot) likely has a bug in this area, though its UX doesn't really lend itself to "prompting" the user. It should probably offer the ability to continue anyways, though.

[turt2live]

This isn't a super realistic thing that can be applied by clients: if the server admin has configured the server so badly that a 10gb JSON file is being served then so be it. It's just not in the server admin's interest to attack bandwidth in this way given the costs they would be incurring from their ISP/service provider.

[KitsuneRal]

At least for native clients (and servers) it's fairly easy to abort on 51201st byte but FAIL_PROMPT looks a bit dubious here: should the client re-request .well-known or rather just continue (rather than abort) receiving the payload after confirming with the user? And yes, generally there's no incentive to attack in that way of course; but a recommendation to protect receiving sides from such misconfigurations wouldn't hurt, would it? Maybe not as MUST but as SHOULD.

[turt2live]

I'm not convinced that this endpoint specifically needs this recommendation though: surely we should be applying this to all endpoints like profiles, sync, etc...

It feels like another MSC's problem.

[aaronraimist]

That's fine, I can leave it to another MSC. The main reason for including it here is because Synapse has already implemented this limit for the server well-known so a well-known bigger than that already isn't going to work with most servers. If it was specced then at least people could expect there is some reasonable limit on the size.

[turt2live]

I would be a bit surprised if people expected 1mb json files to work for this use case, honestly. I think it's reasonable for clients/servers to impose their own limits, and iirc Synapse only really limited the JSON file size on server-server because federation has tiny timeouts (typically), so read delays are not ideal.