I believe that bridges should at least be configurable to require minimal user action and preferably just notify the user about what they're doing. Part of that effort was auto group creation for signal and Telegram (and possibly some day for WhatsApp).
I therefore think that relaying, if available, should be handled automatically.
The relaybot, if available, should be invited automatically when a group is created on the remote platform and there are non-logged in users in the room or a non-logged-in user is invited to an existing portal. Otherwise the inviting user should be set as a relay.
The relaybot should leave when it is no longer needed, as to not expose messages to it unnecessarily. Un-setting the relay user is probably not necessary.
One concern is that someone, typically the bridge admin, has credentials for a dedicated relaybot account, which is a problem if its use is enforced through such an automatism. While a malicious bridge admin can generally eavesdrop on conversations, this would build that into the bridge and make it more likely that it happens by accident, for example when checking on the account to clean up. This can be mitigated by automating clean-up, but ideally the account would be controlled by the appservice, so that regular login is not possible. This, however, would require registering/login to be available from an admin account, which is probably quite a bit of work.
This issue has already been briefly discussed somewhere, but I can't find where. I think it was in one of the rooms, I hope I'm not re-creating a closed issue
I believe that bridges should at least be configurable to require minimal user action and preferably just notify the user about what they're doing. Part of that effort was auto group creation for signal and Telegram (and possibly some day for WhatsApp). I therefore think that relaying, if available, should be handled automatically. The relaybot, if available, should be invited automatically when a group is created on the remote platform and there are non-logged in users in the room or a non-logged-in user is invited to an existing portal. Otherwise the inviting user should be set as a relay. The relaybot should leave when it is no longer needed, as to not expose messages to it unnecessarily. Un-setting the relay user is probably not necessary.
One concern is that someone, typically the bridge admin, has credentials for a dedicated relaybot account, which is a problem if its use is enforced through such an automatism. While a malicious bridge admin can generally eavesdrop on conversations, this would build that into the bridge and make it more likely that it happens by accident, for example when checking on the account to clean up. This can be mitigated by automating clean-up, but ideally the account would be controlled by the appservice, so that regular login is not possible. This, however, would require registering/login to be available from an admin account, which is probably quite a bit of work.
This issue has already been briefly discussed somewhere, but I can't find where. I think it was in one of the rooms, I hope I'm not re-creating a closed issue