Support for authenticated media

[kfiven]

After the landing of matrix-org/matrix-spec-proposals#3916 the profile picture of mxid does not load.

Example: https://matrix.to/#/@ukiradante:matrix.org

[t3chguy]

This will be tricky given that matrix.to doesn't actually have any credentials to authenticate with, it relies on unauthenticated APIs exclusively.

[ShadowRZ]

Giving credentials doesn't seems correct to me, as a credential would only apply to a single homeserver while matrix.to supports using other servers to get the preview.

Also IMO using credentials in matrix.to would complicate the implmentation of matrix.to, as to protect the credential, it should use a server side request to the authenticated endpoints, thus requiring the matrix.to to also have a private endpoint to fetch media itself, very similar to what some bridges should do.

[ara4n]

at the least, we should have the missing profile fail gracefully rather than just looking like this:

[arnowelzel]

But how does it work then with other servers? For example, here the avatar can be loaded without any issue (at least when I checked it):

https://matrix.to/#/@jaywink:federator.dev
https://matrix.to/#/@bubu:bubu1.eu
https://matrix.to/#/@peter.scholtens:matrix4me.nl

Is there any setting in the server to allow avatar downloading without credentials?

Otherwise I would also suggest using a placeholder if the image can not be loaded, similar to the situation when a user does not have an avatar at all:

[nOw-Ay]

@ara4n @arnowelzel, the PR I’m proposing makes image loading fail gracefully by falling back to the placeholder instead of showing nothing. I think this is quite important since many people use matrix.to, and the current behavior gives an “unfinished” impression that isn’t really warranted.

at the least, we should have the missing profile fail gracefully rather than just looking like this:

[xelayz]

Thank you @nOw-Ay

A placeholder would be great.

[elijahr2411]

With authenticated media now required as part of the Matrix specification, the only way that comes to mind that would allow matrix.to to continue displaying user/room avatars is to host a small API service that proxies the avatars to users' browsers using its own private credentials. I've created a proof-of-concept in my fork.

The obvious drawback is that this requires the user/room ID to be sent to the server running matrix.to, which decreases anonymity. To account for this, the implementation in my fork adds a toggle to the server consent screen that lets the user choose whether to fetch the avatar:

Any feedback on this is welcome. Of course, the ideal way to solve this problem would be for a new API endpoint allowing for unauthenticated access to room and user avatars to be added to the Matrix specification, but this would obviously take a long time, so a "middleman" service like this, while not ideal, is likely the only way to restore this functionality for the foreseeable future.