continuwuation/continuwuity

Fork 18

Support for the client-side component of MSC4293: Redact on ban #874

New issue

Closed

opened 2025-06-28 12:24:18 +00:00 by nex · 1 comment

nex commented

2025-06-28 12:24:18 +00:00

Owner

 			PduBuilder::state(body.user_id.to_string(), &RoomMemberEventContent {
 				membership: MembershipState::Ban,
 				reason: body.reason.clone(),
 				displayname: None, // display name may be offensive
 				avatar_url: None,  // avatar may be offensive
 				is_direct: None,
 				join_authorized_via_users_server: None,
 				third_party_invite: None,
 				..current_member_content

The ability to pass through org.matrix.msc4293.redact_events (and in future redact_events) when a user calls /ban into the ban membership allows clients that support MSC4293 to display events sent by the sender as redacted, event without server-side redaction support.

Side note, I don't want to implement this MSC's server-side component until sending actual redactions for events is supported. Right now, the server-side component requires redacting the sender's events in the database and sending the redacted copies over /sync and /messages instead, however, this means that only bleeding edge clients and servers will benefit from this MSC, meaning it's a bit of a waste of time to implement it atm. #872 is more practical and opens more doors in the future.

https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/2e0bb01595be5a7921fe799526bb5f6445715305/src/api/client/membership.rs#L641-L649 The ability to pass through `org.matrix.msc4293.redact_events` (and in future `redact_events`) when a user calls `/ban` into the ban membership allows clients that support [MSC4293](https://github.com/matrix-org/matrix-spec-proposals/pull/4293) to display events sent by the sender as redacted, event without server-side redaction support. Side note, I don't want to implement this MSC's server-side component until sending actual redactions for events is supported. Right now, the server-side component requires redacting the sender's events in the database and sending the redacted copies over /sync and /messages instead, however, this means that only bleeding edge clients and servers will benefit from this MSC, meaning it's a bit of a waste of time to implement it atm. #872 is more practical and opens more doors in the future.

nex added this to the 0.5.0 milestone 2025-06-28 12:24:18 +00:00

nex added the

labels 2025-06-28 12:24:18 +00:00

nex referenced this issue from continuwuation/ruwuma

2025-06-29 12:07:42 +00:00

feat: Add org.matrix.msc4293.redact_events to /ban body #24

nex referenced this issue from a pull request that will close it,

2025-06-29 12:20:10 +00:00

feat: Support passing through MSC4293 redact_events #877

nex commented

2025-06-29 12:26:14 +00:00

Author

Owner

Side note, I don't want to implement this MSC's server-side component until sending actual redactions for events is supported. Right now, the server-side component requires redacting the sender's events in the database and sending the redacted copies over /sync and /messages instead, however, this means that only bleeding edge clients and servers will benefit from this MSC, meaning it's a bit of a waste of time to implement it atm. #872 is more practical and opens more doors in the future.

The MSC clarified that sending redactions is allowed, and travis suggested some ways that servers may decide to issue redactions. I think our best approach would be to issue redactions for all events in room versions before MSC4298 in an one-shot fashion, relying on clients to hide any events that we might miss. Minimum effort, high effect.

For now, we'll stick to just letting clients fight it out.

> Side note, I don't want to implement this MSC's server-side component until sending actual redactions for events is supported. Right now, the server-side component requires redacting the sender's events in the database and sending the redacted copies over /sync and /messages instead, however, this means that only bleeding edge clients and servers will benefit from this MSC, meaning it's a bit of a waste of time to implement it atm. #872 is more practical and opens more doors in the future. The MSC clarified that sending redactions is *allowed*, and travis suggested some ways that servers may decide to issue redactions. I think our best approach would be to issue redactions for all events in room versions before [MSC4298](https://github.com/matrix-org/matrix-spec-proposals/pull/4298) in an one-shot fashion, relying on clients to hide any events that we might miss. Minimum effort, high effect. For now, we'll stick to just letting clients fight it out.

nex closed this issue

2025-06-29 13:07:15 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: continuwuation/continuwuity#874

No description provided.

Rows
Columns