@matthew:matrix.org(i.e. where you hand a slack access token to the bridge and it logs in as you)
@Half-Shot:half-shot.uk(and xmpp :p)
@matthew:matrix.org(DMs are only supported on (Slack in puppetting mode)) to add parentheses for half-shot ;P
@matthew:matrix.orggah, i got it wrong
@matthew:matrix.org(DMs are only supported on Slack (in puppetting mode)) even :P
@matthew:matrix.orgbah, eitherway, to use DMs on slack, you need to be in puppeting mode.
@matthew:matrix.orgthe broken link on that GL issue is now fixed - https://matrix.org/jira/browse/BOTS-133 rides again
@matthew:matrix.orgalthough not quite as pretty as jira used to be
@matthew:matrix.orgbut at least the data isn't lost, and the links are no longer borked
@matthew:matrix.orgso for oauth... i think we may need to better understand what would be authing with what.
@matthew:matrix.orgso we've thought about exposing an oauth2 flow from matrix homeservers so that other systems can authenticate as a user on Matrix with limited scope to do something on Matrix
@matthew:matrix.orgbut i don't think this has ever been formally filed as an issue... and i'm failing to see how it would help with the virtual user concept
@matthew:matrix.orgso i think i might be crosswired; sorry
@Half-Shot:half-shot.ukwhere IMs are just services that provide bots/bridges, but aren't hooked up to any one matrix server and so would be in the same realm as an external service
@matthew:matrix.orgoh, sorry, it might
@matthew:matrix.orgalthough it's not oauth2
@matthew:matrix.orgyou're saying "hey, i want to log into an IM with my matrix creds" is the same as "i want to log into gitter with my matrix creds"
@matthew:matrix.orgbut it's not like we're hosting an oauth2 flow currently
@Half-Shot:half-shot.ukSimilarly to how we pulled off the early experiments with bifrost
@matthew:matrix.orgyeah, that sounds like it's what Eric Eastwood (Gitter) is suggesting
@matthew:matrix.orgbut i don't think the openid API is good enough for that
@Half-Shot:half-shot.ukI have next to no idea how openId functions aside from passing tokens and eventually ending up with an identity.
@Half-Shot:half-shot.ukSo that's not really a good soln
Half-Shot: How does Matrix initialize the "virtual user" process? How does Matrix initialize the auto-puppeting process?
It seems like those flows can also apply to logging into Gitter with Matrix OAuth. And since it is Matrix, there can be some assumptions about automagically knowing the credentials, etc
@Half-Shot:half-shot.uk Hm, so it could work but I'm trying work out how we could do it without manual steps from the user. Essentially when a matrix user interacts with the bridge for the first time, you would try to register the user on Gitter. Ideally using some kind of token which could uniquely identify the user rather than a user/pass combo.
However, what I have essentially described here is our appservice API
@Half-Shot:half-shot.ukSo perhaps that is the best way. Some unique secret token shared between gitter and matrix that allows the bridge to register new users, but reuse the same token.
nvm, would require some other requests before. I assume we can automate OAuth?
Wondering about this, gitlab-org/gitter/webapp#533
webappif we don't have to
@mr-c The best place to track is https://gitlab.com/groups/gitterHQ/-/epics/10
The "Gitter Integration (legacy)" bot/user is from the migration script that is being run to cut everyone over to the new bridge. The old bot joins the new room to ensure the tombstone pointer to the new room works