Summary
Currently bridgev2 ignores m.room.pinned_events state changes. They fall through to the default case in handleMatrixEvent and are silently dropped. This means network connectors have no way to handle pin/unpin actions coming from Matrix.
I'm working on adding message pinning support to mautrix-whatsapp (mautrix/whatsapp#905). The WhatsApp to Matrix direction is already working by updating the room's m.room.pinned_events state directly. However, the Matrix to WhatsApp direction requires bridgev2 to dispatch pinned events state changes to the connector.
What's needed
A new PinHandlingNetworkAPI optional interface, following the same pattern as RoomNameHandlingNetworkAPI, TagHandlingNetworkAPI, and other existing handler interfaces. This would allow connectors to receive pin/unpin actions from Matrix with the added and removed event IDs, so they can be forwarded to the remote network.
I'm happy to implement this if the approach sounds good.
Summary
Currently bridgev2 ignores
m.room.pinned_eventsstate changes. They fall through to thedefaultcase inhandleMatrixEventand are silently dropped. This means network connectors have no way to handle pin/unpin actions coming from Matrix.I'm working on adding message pinning support to mautrix-whatsapp (mautrix/whatsapp#905). The WhatsApp to Matrix direction is already working by updating the room's
m.room.pinned_eventsstate directly. However, the Matrix to WhatsApp direction requires bridgev2 to dispatch pinned events state changes to the connector.What's needed
A new
PinHandlingNetworkAPIoptional interface, following the same pattern asRoomNameHandlingNetworkAPI,TagHandlingNetworkAPI, and other existing handler interfaces. This would allow connectors to receive pin/unpin actions from Matrix with the added and removed event IDs, so they can be forwarded to the remote network.I'm happy to implement this if the approach sounds good.