Improve awareness of audience when bridging conversations (enhancement)

[pleasantone]

I've received feedback from potential users concerned about security when conversation bridging.

Currently, when one is on a hangout, there are three methods we have available to us:

1. One can can list all the users
2. One can query G+ to see what their relationship is to a questionable user
3. One receives notification any time someone joins/leaves the hangout.

We're missing those when we bridge between hangouts or between hangouts and Slack/Telegram/etc.

1. It would be nice to have a command that could send (via 1:1 ala help) the list of every member, regardless of which technology they are using to talk in HOs.
2. Where possible, in that output, provide a G+ profile link (with Slack/Telegram, maybe something else)
3. Announce on all bridged conversations when someone leaves/joins any of the bridged conversations. (all but the conversation where the membership changed, since that's handled natively)

[endofline]

thought of this (kludgy) specification:

• register a shared function with pattern chatbridge_<behaviour>_<plugin>, where <behaviour> = "userlist", plugin = plugin name
• filter callables by prefix, find all shared functionality for chatbridge_listusers_*, execute each callable, compile results and output

in the case of "behaviour" listusers, each callable should accept a hangouts conversation id. each plugin that registers their own platform-specific callable should receive the conversation id, and return the users for linked external rooms.

due to the nature of the calls, user enumeration must happen live, no caching can occur (unless its already in-built like hangoutsbot permamem), so this might result in somewhat heavy hits against each chat client for large groups

i'll be happy to entertain other ideas though, this is pretty much in the conceptual stages

[Terrance]

Since bridge plugins subclass WebFramework, could this provide a list_users() method or similar, which can be overridden per subclass to provide its own member list? Then the user-facing command can just call that method for all known bridges linked to the current conversation (possibly de-duping identified users that appear over multiple protocols).

Could have a similar method for whois(user) that takes some form of identifier, and returns standard fields like full_name, user_id, photo_url etc. specific to that protocol.

[pleasantone]

FWIW, I would love to see this become a 'standard' part of the chat bridge API, where each plugin can provide basic commands like "who is on my side of the chat" and a consolidated command gives all participants. Said command should not be slack/sync/tg specific, but really "Who the heck can see what I write?" How you guys implement it, I'm not too worried about, just as long as it's standard and clean and works for all cases.

[Terrance]

I started toying with this, hit a few bumps along the way though:

• No global tracking of bridges -- they register their own message handlers, but are otherwise independent. I'm currently making each WebFramework instance add itself to bot.shared["webbridge"].
• No chatbridge-global plugin for shared commands, so plugins._chatbridge is handling it for now.
• No easy way to traverse syncrooms, Unlike all other bridges, which connect a hangout to a third-party room, syncrooms links two or more hangouts, and each may have further connected rooms (including more hangouts from another syncrooms bridge!).

I think we need some sort of discovery system, so you (by which I probably mean plugins, or the bot in general) can query a hangout ID and get back a standard data structure. A list of bridge instances, each with a list of their individually synced rooms, and each of those with their list of participants. Then we can have commands like getmembers that pull out the relevant info and display it to the user.