Consider puppeting of Gitter user accounts

[leonerd]

Users have expressed an interest in being able to give the bridge their gitter-side user credentials so that it can puppet for their actual user account instead of relaying messages via matrixbot.

[leonerd]

This looks superficially simple but comes with huge amounts of hidden complexity.

Currently the bridge has an easy life, because any messages appearing on either side that come in from humans (or at least, entities external to the bridge) get relayed onto the other side by entities entirely under its control - the matrixbot relaybot user on Gitter, or the various @gitter_* ghosts on Matrix. This means that any given user-account only requires one-way sync. Whatever a real Matrix or Gitter-side "human" does, the bridge just does the same thing with one of its ghosts on the other side and all is good.

If we were to allow user-account puppeting, there are lots of new situations that arise that require consideration, because there are humans operating both sides of the same "linked user entity" and that may put the bridge into a situation it cannot easily synchronise.

There are questions of what the bridge does to synchronise state at the moment the two accounts are linked:

1. At the moment the user sets up this link between gitter and matrix accounts, what happens about userlist syncing? Does their gitter-side user now join every gitter-side room that the bridge has linked just because their matrix-side user is in the other side of the room? Or do we join them lazily the first time the matrix-side user speaks?
2. Related to above, what happens at the time the user disassociates their accounts - would the bridge now have to puppet the gitter-side user to leave any gitter-side rooms that were only joined because of that previous association? What if the user wanted to remain there?
3. Existing user accounts are likely to already have a "displayname" set in both systems. At the moment of linking how do we cope if they are not identical? If one changes going forward, do we attempt to synchronise it with the other?
4. Harder than a displayname is the avatar image. With a displayname we can just compare strings to see if they're equal, but with avatar images there might be serverside compression or scaling going on that means the "same" image is no longer bytewise identical.

There are also situations involving creating or removing matrix-to-gitter room associations and what we do about user accounts in those rooms:

1. At the moment a new matrix-to-gitter room association is created, same question as above. Does the bridge puppet their gitter user accounts to join the gitter room?
2. At the moment that an existing matrix-to-gitter room association is removed, how do we handle gitter-side user accounts in the gitter room? Do we just remove them?

These are questions that are new to the Gitter bridge for which there is no precedent in the IRC bridge because Gitter user account state persists longer than a single control connection to the gitter server, unlike in IRC.

In some ways, the question about displaynames is similar to the question of topic sync between Matrix and 3PNs (e.g. the IRC bridge already solves this to some extent).

(edited)

[yangm97]

I would say users, at least I, would expect matrix to act as a gitter client. I know, that's not how bridges work, but I think this would cause the least trouble.

[PureTryOut]

Definitely. This would also be used in the case of Telegram, to make 1-on-1 conversations to Telegram users possible from Matrix.

[leonerd]

I've moved out the question of puppeting the matrix-side accounts into a new issue - #33.

[leonerd]

Right. That list of questions above has now been edited quite a bit, some of the questions moved out to #33. All of the above remain valid and still require resolving before I can make much progress.

[leonerd]

Speaking of progress however, I do have the very start of some experimenal code, on https://github.com/matrix-org/matrix-appservice-gitter/tree/paul/users-and-ghosts

Right now it requires a bunch of hand-crafted curl requests to perform the OAuth2 dance to get a user token and then hand-editing of vim user-store.db to put that token in the database, but if one is found there the bridge will now use it when relaying messages from matrix-side users. This code does not yet address any of the concerns listed above.

Nor does it begin to address how regular users will actually complete that OAuth2 dance for themselves. This too is a question that needs answering.

[kegsay]

At the moment the user sets up this link between gitter and matrix accounts, what happens about userlist syncing? Does their gitter-side user now join every gitter-side room that the bridge has linked just because their matrix-side user is in the other side of the room? Or do we join them lazily the first time the matrix-side user speaks?

Upon a successful link to a "real" gitter account, I would treat that real account as the ghost, replacing it in all rooms automatically. So yes, their gitter-side user now joins every bridged room. This has perf implications due to the churn of leaves/joins this would create though, so a lazy-option may be nice.

The fact remains though that the human has explicitly said to the bridge "use and abuse my real gitter user please", so we should honour that and not use the ghost anymore IMO.

Related to above, what happens at the time the user disassociates their accounts - would the bridge now have to puppet the gitter-side user to leave any gitter-side rooms that were only joined because of that previous association? What if the user wanted to remain there?

Replace the real user with the ghosted user as if they never associated their account in the first place.

Existing user accounts are likely to already have a "displayname" set in both systems. At the moment of linking how do we cope if they are not identical? If one changes going forward, do we attempt to synchronise it with the other?

Have it as an option to sync across the display name (prefer: Gitter / prefer: Matrix / prefer: Neither (no sync)).

Harder than a displayname is the avatar image. With a displayname we can just compare strings to see if they're equal, but with avatar images there might be serverside compression or scaling going on that means the "same" image is no longer bytewise identical.

Cheat. There are 3 options:

• Copy the Gitter image to Matrix.
• Copy the Matrix image to Gitter.
• Do not copy.

These don't require comparisons to perform. You just need to fetch the bytes, send them over, then mark that you have synced them.

[leonerd]

An initial attempt at this is now running in production, from the https://github.com/matrix-org/matrix-appservice-gitter/tree/paul/users-and-ghosts branch.

This does not attempt to address any concerns other than the minimal required to echo individual message lines into Gitter. In particular:

• It will not cause the puppeted gitter user account to join or leave any room, for any reason
• It will not attempt to synchronise displayname or avatar image changes

In addition, there's currently no place on the Riot web UI for users to begin the OAuth2 authorization flow, so to obtain the starting URL for that people will have to ask me to generate one and I'll send it via a 1:1 room.

[leonerd]

Latest excitement: if the bridge isn't going to puppet room joins, then it can get stuck in a situation where a puppeted user needs to talk in a gitter room their user account isn't in. I suspect the only sensible thing to do here is for it to revert to using the relaybot as would be the case if it didn't have that user-specific puppet.

This leads to the situation where we need to keep watch for the puppeted users joining/leaving rooms, so as to keep an accurate idea of what rooms we can puppet user accounts into

[leonerd]

Well. Hrm. Except it turns out that public gitter rooms allow you to post into them regardless of whether you're currently a member of it anyway. As if an IRC channel set to -n. So we don't need to check after all.

[jcgruenhage]

Any progress on that?

[devnoname120]

@leonerd What is the status on this issue? Gitter users regularly complain that the integration is suboptimal.

[leonerd]

I'm afraid I haven't been working for Matrix for the past few months any more.

Last time I was working on it, the bridge itself has all the right pieces, and it was just waiting for someone who knows how to write the web frontend parts, to write the necessary UI to allow users to provision it themselves in Riot or similar. Lacking that, it requires someone with access to the bridge admin console, to generate per-user URLs so users can set up the linkage themselves. As far as I know, the only person with such access remains to be me.

[leonerd]

Though I suppose without that UI in Riot et.al. there could be a provisioning method involving sending a direct message to the bridge bot user somehow. That would be a new bit of code flow that would need adding to the bridge, but would bypass the dependency on frontend UI developers.

[joenas]

There's work being done on other bridges to add a provisioning. See https://github.com/turt2live/matrix-appservice-webhooks/blob/master/PROVISIONING.md for an example!
I have a bridge myself where I'd like to add it but lack the time atm :/

[devnoname120]

Though I suppose without that UI in Riot et.al. there could be a provisioning method involving sending a direct message to the bridge bot user somehow. That would be a new bit of code flow that would need adding to the bridge, but would bypass the dependency on frontend UI developers.

This would be great. And once it is implemented, the UI could follow.

[yangm97]

Bump?

[JuniorJPDJ]

bump? ;/

[ildar]

Gitter seem to finish their part of the job of replacing matrixbot with something user-name contained: https://gitlab.com/gitlab-org/gitter/webapp/-/issues/1076
When our bridge would start using the feature?