[Story] Public content display policy

[manuroe]

Description

• As a homeserver admin
• I want to set the public media content display policy for my users
• So that they can safely their matrix app even in the context of an open federation

Scope

The new server policy setting will have impact on:

• Display of previews and thumbnails of media in timelines of public rooms
• Display of invite avatars

Acceptance criteria

• A new MSC defines the behavior
• Client follows the MSC. It also defines the fallback behavior if there is no policy defined by homeserver
• If the user did not change the app settings added in [Story] Advanced settings for hiding invite avatars and timeline media #2788, server settings apply
• If they changed the app settings, app settings apply

Dependencies

• MSC4278: Media preview controls matrix-org/matrix-spec-proposals#4278 must be deployed on the matrix.org homeserver before applying the fallback behavior client side.

Out of scope

• Nothing

Questions

• Should we have separated settings, one for invite, one for images in the timeline? --> Yes
• Is scoping the impact on public rooms good enough?
• Invite: Should we display the avatars on tap? -> No
• What should be the server setting value media_previews for m.org? Private may be safe enough --> it is going to be 'on'
• Do we need work in the SDK or Ruma? --> Yes

Subtasks

Android

• [Task] Set hide timeline media and invite avatars flag through the homeserver element-x-android#4439

iOS

• [Task] Set hide timeline media and invite avatars flag through the homeserver element-x-ios#3923

Web

• Global configuration flag for media previews element-web#29582

Other

• MSC4278: Media preview controls matrix-org/matrix-spec-proposals#4278
• Update the MSC to have fallback values to be on to avoid unexpected app behavior changes for end users

[Velin92]

when we say we want to hide avatars in invites we mean:

• the avatar of the inviter in the room preview screen
• and also the avatar of the room to which you have been invited (if the room is not a DM) in the room preview screen
• the avatar of the invite cell in the room list screen
• the avatar of the inviter in the invite cell in the room list screen
• the avatar of the invite in the push notification

Also when we say hide the avatar, we are okay just not showing the actual image through the URL, but we are okay in displaying the placeholder initials right?
Or we want to use something like a removable blur? (this ofc won't work for the push notification, so I guess in that case we may need to just use the initials)

@manuroe @amshakal

[amshakal]

That's exactly right. Yes to all the scenarios you mentioned.

And yes, let's show initials instead of blurring.

[Velin92]

That's exactly right. Yes to all the scenarios you mentioned.

And yes, let's show initials instead of blurring.

Initials everywhere or just for the notification?

[Velin92]

@manuroe @mxandreas
Had a chat with @poljar about this, we would also need to add these two new values to Ruma to be able to support them, since they would need a default value when the hs does not provide them, and a specific enum type for each of them. So is not as easy as just adding them in the FFI layer, on the SDK side.

[Velin92]

We also need this: matrix-org/matrix-rust-sdk#4994

This PR would be very useful because it allows to onserve the account data value in real time

[Velin92]

The Rust PR is merged, and an iOS PR is about to be merged, I want to point out that this implementation is very basic since:

• We only set the UNSTABLE prefix version of the event
• We only set the global account data event, we did not yet implement the room specific ones
• A migration has been implemented, so that if the server has no current configuration, and the user has a local one, we set it on the server and then remove the local one.

However this should be sufficient for the acceptance criteria, but is important that the SDK gets updated to use the stable event once the MSC is shifting to a stable prefix.

[manuroe]

Just tested with the current nightlies and develop. The features works well. There is only a UI parity issue where the ordering on iOS is not the same as on Web and Android.
@Velin92, can we fix it?

Once patched, we can close this story.

Web	Android	iOS

[Velin92]

Just tested with the current nightlies and develop. The features works well. There is only a UI parity issue where the ordering on iOS is not the same as on Web and Android. @Velin92, can we fix it?

Once patched, we can close this story.

Web Android iOS

Okay will fix it immediately in this PR: element-hq/element-x-ios#4294