#bridge
2021-03-27
@pm5 has joined the channel
@aelcenganda has joined the channel
@patcon has joined the channel
@flyingmars has joined the channel
Patrick Connolly
Re: @pm5's #facing-the-ocean. Realized I didn't want to share "meta" stuff in that channel in case noisy, but here are some bridge docs:
We can probably use this place to discuss thing related to bridge and translation?
Ahhh great point!
Heh looks like we created #chat-bridge way back in the day too š
- š1
- š®1
2021-03-28
So I took a look at the code of matterbridge. Sadly there appears to me no clean interface to inject a translation service, something like a plugin system. However on mattermost there are things like autotranslate plugin https://github.com/mattermost/mattermost-plugin-autotranslate
The Mattermost plugin seems neat btw!
Unlike most translation tools I've seen, it _seems_ to translate messages for everyone when one person requests it, which feels important to create a consensus reality where everyone knows what everyone knows. Every tool I tested didn't do this -- they'd just translate per-user client-side, usually when someone clicked a hidden menu. And so it was an isolating experience where a foreign speaker who knew about the feature could technically read, but they knew most speakers didn't know about it, and they couldn't know what other foreign speakers were seeing
Just some odd dynamics there, that work against foreign participation
Unlike most translation tools I've seen, it _seems_ to translate messages for everyone when one person requests it, which feels important to create a consensus reality where everyone knows what everyone knows. Every tool I tested didn't do this -- they'd just translate per-user client-side, usually when someone clicked a hidden menu. And so it was an isolating experience where a foreign speaker who knew about the feature could technically read, but they knew most speakers didn't know about it, and they couldn't know what other foreign speakers were seeing
Just some odd dynamics there, that work against foreign participation
There is also intergromat but it's not opensource https://www.integromat.com/en/integrations/mattermost
Integromat
Integromat gives you the ability to integrate Mattermost with many other services.
@helloworld_bot has joined the channel
yo
2021-03-29
That's for research pm5. Yeah, my feature felt quite messy :)
Do you suggest a Mattermost plugin because it seems there's a relation between matterbridge and Mattermost? (The name is quite misleading, and simply historic, as Mattermost is no more central than Whatsapp or Slack or Telegram to the bridges functioning)
It's a frequent point of confusion in the issue queue of matterbridge š
Ah, found the wiki page for the "extension" system I was thinking of: https://github.com/42wim/matterbridge/wiki/Tengo
I don't know if it powerful enough rn as an interface, but maybe there's a path of modifying it to add the hooks we need available at that interface?
Could maybe even have it call an external API service that we create for coordinating translations, so we could write it in something besides golang
Had doubts about this, as not sure how full-featured tengo script is, but seems it might be possible: https://github.com/d5/tengo/issues/107
@katiaiam7 has joined the channel
@kirstenliu has joined the channel
@patrick.c.connolly_br has joined the channel
Just adding ppl who were in the old room, just in case still interested :)
Had doubts about this, as not sure how full-featured tengo script is, but seems it might be possible: https://github.com/d5/tengo/issues/107
I mentioned mattermost because we have a mattermost instance, and because it would be better if we can keep each of the parts do one thing well.
If bridge is doing a good work on bridging, it doesn't make a lot of sense asking it to do more. We could add translation elsewhere, like on one end of the bridge.
If bridge is doing a good work on bridging, it doesn't make a lot of sense asking it to do more. We could add translation elsewhere, like on one end of the bridge.
Interesting. I appreciate unix philosophy, but I guess I had opposite sensibility here: unix philosophy struck me as favouring the most low-level decomposable tool, which I thought would be translating in the service-agnostic bridge tool.
Plus, I'm a little biased in that Code for All was interested in translation in their Slack, and I was eager to support that. I'm also not in any communities that use Mattermost, and so if the solution is a Mattermost plugin, this becomes an initiative that my other community spaces have no stake in š¤·š»
Which is perfectly ok, to be clear -- this has momentum of its own and I don't necessarily need to be a part of it :)
Also, just realized something: were you thinking that translated messages in Mattermost would get passed through the bridge to other places?
Well, mattermost has a few advantages to the bigger view of communication. Slack is hard to scale in terms of secondary features like message history, limits of number of apps installed, etc. And building an infrastructure for alternatives is one of my motivations of working on a stable bridge service. We have also been criticized in the past of supporting proprietary solutions instead of open source, community-owned solutions. But that is entirely another topic.
So I think there is clearly different views here of the scope of the project. As I said, I will mostly focus on maintenance and monitoring of the bridge as my priority, so for translation, I'm totally fine if someone implements it in its own approach first. Those things above were just for sharing some thoughts of how I would approach it if I'm doing it now. They may change (quickly) over time, too. (Tengo looks nice)
It's mainly if matterbridge can support the kind of extension we have in vision. I would hope we can have users setting up their own bridges across communities, with consents from both sides, and people from both sides would be actively reminded of these connections. I would hope we can provide these features with bot commands/dialogues because it seems more friendly to the users. It doesn't seem feasible to pack all these things into matterbridge, so there needs to be some way of connecting the bridge to a bot program. If matterbridge is currently only focusing on bridging two ends with limited ability to translate the messages, then one of the ends could be a place to inject a bot program. So a separated center of exchange for messages comes up into the picture. Mattermost just might be a clear choice for it nowadays because of the limitations of slack.
Again, all of these do not have to be in the scope of a translation bridge. And we are still in POC stage anyway so none of these needs are justified even the slightest.
š (me throwing out ideas) š¤
> It doesnāt seem feasible to pack all these things into matterbridge
Totally. I appreciate your thoughts and ideas @pm5 :)))
Totally. I appreciate your thoughts and ideas @pm5 :)))
I think the angle I took before was that the really custom āmanagementā stuff is something else that just ābuildsā the toml matterbridge config. thatās where all the magic logic is (consent, interactions, config, etc). If matterbridge can read a remote config file, then only a small bit of basic translation logic need go into matterbridge itself. the rest of the cleverness is another app that manages the config (and maybe creates nice UIs around that)
Iām aspiring to stay open to the idea of using data from a plugin! š i just have this prickly pessimism from what i recall of the event-driven model of core matterbridge, which makes me feel it could be quite messyā¦!
pessimism is not a good place to stand! but iām just acknowledging it to be candid šš»
The Mattermost plugin seems neat btw!
Unlike most translation tools I've seen, it _seems_ to translate messages for everyone when one person requests it, which feels important to create a consensus reality where everyone knows what everyone knows. Every tool I tested didn't do this -- they'd just translate per-user client-side, usually when someone clicked a hidden menu. And so it was an isolating experience where a foreign speaker who knew about the feature could technically read, but they knew most speakers didn't know about it, and they couldn't know what other foreign speakers were seeing
Just some odd dynamics there, that work against foreign participation
Unlike most translation tools I've seen, it _seems_ to translate messages for everyone when one person requests it, which feels important to create a consensus reality where everyone knows what everyone knows. Every tool I tested didn't do this -- they'd just translate per-user client-side, usually when someone clicked a hidden menu. And so it was an isolating experience where a foreign speaker who knew about the feature could technically read, but they knew most speakers didn't know about it, and they couldn't know what other foreign speakers were seeing
Just some odd dynamics there, that work against foreign participation
Interesting. I appreciate unix philosophy, but I guess I had opposite sensibility here: unix philosophy struck me as favouring the most low-level decomposable tool, which I thought would be translating in the service-agnostic bridge tool.
Plus, I'm a little biased in that Code for All was interested in translation in their Slack, and I was eager to support that. I'm also not in any communities that use Mattermost, and so if the solution is a Mattermost plugin, this becomes an initiative that my other community spaces have no stake in š¤·š»
Which is perfectly ok, to be clear -- this seems to have momentum and I don't necessarily need to be a part of it :)
Interesting. I appreciate unix philosophy, but I guess I had opposite sensibility here: unix philosophy struck me as favouring the most low-level decomposable tool, which I thought would be translating in the service-agnostic bridge tool.
Plus, I'm a little biased in that Code for All was interested in translation in their Slack, and I was eager to support that. I'm also not in any communities that use Mattermost, and so if the solution is a Mattermost plugin, this becomes an initiative that my other community spaces have no stake in š¤·š»
Which is perfectly ok, to be clear -- this has momentum of its own and I don't necessarily need to be a part of it :)
Also, just realized something: were you thinking that translated messages in Mattermost would get passed through the bridge to other places?
2021-03-31
Well, mattermost has a few advantages to the bigger view of communication. Slack is hard to scale in terms of secondary features like message history, limits of number of apps installed, etc. And building an infrastructure for alternatives is one of my motivations of working on a stable bridge service. We have also been criticized in the past of supporting proprietary solutions instead of open source, community-owned solutions. But that is entirely another topic.
So I think there is clearly different views here of the scope of the project. As I said, I will mostly focus on maintenance and monitoring of the bridge as my priority, so for translation, I'm totally fine if someone implements it in its own approach first. Those things above were just for sharing some thoughts of how I would approach it if I'm doing it now. They may change (quickly) over time, too. (Tengo looks nice)
It's mainly if matterbridge can support the kind of extension we have in vision. I would hope we can have users setting up their own bridges across communities, with consents from both sides, and people from both sides would be actively reminded of these connections. I would hope we can provide these features with bot commands/dialogues because it seems more friendly to the users. It doesn't seem feasible to pack all these things into matterbridge, so there needs to be some way of connecting the bridge to a bot program. If matterbridge is currently only focusing on bridging two ends with limited ability to translate the messages, then one of the ends could be a place to inject a bot program. So a separated center of exchange for messages comes up into the picture. Mattermost just might be a clear choice for it nowadays because of the limitations of slack.
Again, all of these do not have to be in the scope of a translation bridge. And we are still in POC stage anyway so none of these needs are justified even the slightest.
š (me throwing out ideas) š¤
> It doesnāt seem feasible to pack all these things into matterbridge
Totally. I appreciate your thoughts and ideas @pm5 :)))
Totally. I appreciate your thoughts and ideas @pm5 :)))
I think the angle I took before was that the really custom āmanagementā stuff is something else that just ābuildsā the toml matterbridge config. thatās where all the magic logic is (consent, interactions, config, etc). If matterbridge can read a remote config file, then only a small bit of basic translation logic need go into matterbridge itself. the rest of the cleverness is another app that manages the config (and maybe creates nice UIs around that)
Iām aspiring to stay open to the idea of using data from a plugin! š i just have this prickly pessimism from what i recall of the event-driven model of core matterbridge, which makes me feel it could be quite messyā¦!
pessimism is not a good place to stand! but iām just acknowledging it to be candid šš»
is there a codebase for the bridge being used? sorry, i think maybe someone answered that, but i canāt find the msg š Iām just looking for where the matterbridge config is stored, so i can poke around and see the state of things