Here's a challenge from Carla's team. I don't yet know how we might want to present this on the website.
What happens on the other side? Making data-handling differences visible in Matrix conversations
Bridges let Matrix users talk with people on Telegram, Slack, Discord, and other platforms, which greatly extends Matrix's reach. When a message crosses a bridge, it enters a system with different rules: it may be stored on the other platform's servers, kept longer than your own server's retention policy allows, or be visible to people and services you didn't expect. Matrix already offers some hints that a room is bridged, such as bridge information in room settings and recognizable bridged user accounts, but these mostly tell you that a bridge exists, not what it means for your messages, and they are easy to miss. Different Matrix clients may also do different things with a message once it is decrypted, such as sending a voice message to a third-party service for transcription, and the sender has no way of knowing.
The challenge: How could Matrix conversations let people know when the conditions governing their messages change? Explore this on either side, or both:
Protocol: What would bridges and clients need to declare about how they handle messages (for example encryption, retention and deletion, and who else can access the content), and how could that be expressed as an extension to Matrix?
Interface: How should this appear to users? For example, as a notice when a bridged participant joins, a marker on a profile, a label on individual messages, or a warning before sending.
Sketches, mockups, a proof of concept in an existing client, or a draft protocol proposal are all welcome.
Originally posted by @andypiper in #250
Originally posted by @andypiper in #250