fix(MSC3911): reorganize profile avatar validation to account for remote media #136
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Forgot to account for setting a profile avatar based on remote media that our local server has no data on. Since this is allowed to be set by spec, we probably should not error on it. It may end up being that the media is unrestricted.
The chances that a remote media piece that we have no data on being used as a profile avatar is really slim. The user setting the profile avatar would have had to have gotten the MXC from somewhere and would have to type it in by hand. The likelihood that they got it passed to them on a Post-it Note or something is slim, but not outside the realm of possibility.
Even if a profile avatar is set to a piece of media that the local server finds out is restricted later, it will still error on the
/downloadand/thumbnailendpoints. This may not be the best in user experience, but has prior art for how media is handled pre-msc3911 when it does not exist or is otherwise inaccessibleAlternatively, we maybe could do something fancy where we attempt to retrieve the media from the remote server and do an internal copy on it like we do for profile avatars/membership events. This would require a new HTTP replication call(for the media retrieval) at the very least