Consider puppeting of Matrix user accounts

[leonerd]

This issue split out from #31

If we hypothetically had the ability to perform an OAuth2 dance with synapse and give matrix-appservice-gitter a token to puppet for matrix-side accounts, this would give us a nice symmetry. Why should the matrix-side account be considered the "primary" and the gitter-side one a relay? What if the user wants the gitter-bridge to puppet their matrix account to relay things that they are doing in the gitter side via a real gitter client? If the user is happy to allow the bridge to puppet their gitter account, why not puppet their matrix account too?

It simplifies some of the problems with only having one-way puppetting, and doesn't really make any of the other problems any worse.

[leonerd]

In particular, the following problems (moved from #31) all go away if the bridge gets full bidirectional puppeting in both directions simultaneously:

1. When a real gitter user uses their real gitter client to speak in a bridged room - how do we relay that back to matrix?
2. When a real gitter user leaves a gitter room in their real gitter client - if we're performing full user-list syncing surely we'd just force them back in again?
3. When a real gitter user for which we are puppeting joins a new gitter-side room that we happen to be bridging into matrix already - what should the matrix side look like?

These are questions that are new to the Gitter bridge for which there is no precedent in the IRC bridge (because the bridge would never be able to puppet the same IRC-side user account while the user is using it, as IRC does not allow multiple connections of the same user), nor in the Slack or other bridges (because we haven't implemented similar functionality there).

[kegsay]

When a real gitter user uses their real gitter client to speak in a bridged room - how do we relay that back to matrix?

I don't follow what this has to do with the Gitter bridge having auth for a real Matrix account. If "a real gitter user uses their real gitter client to speak in a bridged room" you make a Matrix ghost and speak, just as any bridge does.

When a real gitter user leaves a gitter room in their real gitter client - if we're performing full user-list syncing surely we'd just force them back in again?

See above. You just part the Matrix user the bridge created?

When a real gitter user for which we are puppeting joins a new gitter-side room that we happen to be bridging into matrix already - what should the matrix side look like?

We would need the ability to force join the matrix user to the bridged room.

[IngwiePhoenix]

Four years later...and Gitter puppeting is still not a thing.

Any news on that, so far? This issue is also still open.