Expose the redact endpoint to widgets

[ghost]

Your use case

What would you like to do?

I'd like to delete events using the Widget API. Currently it is not possible to send m.room.redaction events via the Widget API because the redacts key is outside the content object and gets stripped by Element when I try to send the event using .transport.send(). I was told that it's because these events require a special endpoint that's not currently supported by the API.

Why would you like to it?

My widget is an interactive whiteboard that allows users to add, edit or delete shapes - both one's own and those added by other users. Using m.room.redaction seems like the most straightforward way to get rid of shapes that were deleted from the whiteboard.

How would you like to achieve it?

A method called .sendRedactionEvent that takes the ID of the event to be redacted as a string would be perfect.

Have you considered any alternatives?

The only alternative I can think of is collecting the IDs of the 'deleted' events in a special state event and then filtering them out based on that list after calling .readRoomEvents().

Additional context

No response

[ghost]

https://github.com/matrix-org/matrix-doc/issues/502

[turt2live]

brief thoughts on this are to make MSC2762 manually move the redacts key down into content over the widget transport, hoisting it to the /redact endpoint on the client side.

[dbkr]

This could be a useful enough feature in general, although I would point out for you specific use case that if you posted a separate 'delete shape' event, you'd get a complete, replayable history of the whiteboard for free, whereas if you redact the event, its content will be erased, so you may want to reserve redaction for when someone accidentally paste their email password into the whiteboard and you really do want to pretend it never happened. 🤷

[skolmer]

This could be a useful enough feature in general, although I would point out for you specific use case that if you posted a separate 'delete shape' event, you'd get a complete, replayable history of the whiteboard for free, whereas if you redact the event, its content will be erased, so you may want to reserve redaction for when someone accidentally paste their email password into the whiteboard and you really do want to pretend it never happened. 🤷

Our current plan is to track a client side history so you can undo and redo your latest changes. At least since the client was started (basically send a new event with the previous deleted content).
A typical use-case for the redact event would be to get rid of inappropriate content that is shared on a collaborative session... which happens quite often in the education sector 🙈

[ghost]

This could be a useful enough feature in general, although I would point out for you specific use case that if you posted a separate 'delete shape' event, you'd get a complete, replayable history of the whiteboard for free, whereas if you redact the event, its content will be erased, so you may want to reserve redaction for when someone accidentally paste their email password into the whiteboard and you really do want to pretend it never happened. 🤷

@dbkr You have a point there. Also, we've been using room events for this, but now that I think about, wouldn't using state events make more sense? Never really understood the difference between the two.

[turt2live]

State events are useful if you don't want history of the changes, and are quite heavy on the room. Room events are better for streaming or stream-like data where a record of what happened when is important.