search

matrix-org / matrix-federation-tester

Tester for matrix federation written in golang.
78 stars 17 forks source link

Consider reworking how server discovery is represented #72

Open aaronraimist opened 5 years ago

aaronraimist commented 5 years ago

@ace:kittenface.studio and @grin:grin.hu pointed out that the way the federation tester displays how a server was discovered can be confusing.

@ace:kittenface.studio says that instead of having individual lines saying that well-known wasn't found or an SRV record wasn't found it would be better to say which method was used to discover the server. For example something like

Server was discovered via .well-known and SRV or Server was discovered directly on port 8448

That way an admin who thought they had setup a correct well-known file, but saw the server was only discovered using the SRV record for example would know that something was wrong with their well-known file. Using something like this, server admins who don't need a well-known (or don't need an SRV) wouldn't be confused that they were missing some required thing which a lot of people seem to think when they see well-known not found in the federation tester currently.

Screen Shot 2019-03-21 at 10 43 28 AM https://matrix.to/#/!QtykxKocfZaZOUrTwp:matrix.org/$155300756116915ZJdON:kittenface.studio?via=matrix.org&via=half-shot.uk&via=linuxgaming.life

Moved from a comment in #70

babolivier commented 5 years ago

While I agree that presenting it this way would be much clearer, "reworking" makes me think of ditching all of the existing and replacing it with something else. I'd rather have, let's say, an additional resolution_flow property at the top-level of the report which would have an array of strings as its value (["srv"] for SRV, [".well-known"] for .well-known, [".well-known", "srv"] for SRV of a .well-known result, etc). wdyt?