Does chat support have to built into the matterbridge binary?

[jakubgs]

If I wanted to develop bridging functionality for https://status.im/, would that have to be built into MatterBridge itself, or could it have a form of a library loaded on runtime?

I couldn't find any clear instructions on how to extend MatterBridge with your own chat support, but from what I've gathered the only way is to fork MatterBridge and add that functionality to its codebase. Is that right?

[Helcaraxan]

Hello @jakubgs.

There are two ways in which Matterbridge can support a new protocol:

• You can, as you already suggested, build it into the binary by adding native support for the targeted chat protocol. Instead of using a fork it would be encouraged to contribute this new native support to the core repository via one or more PRs. Before going down this road please do discuss the way in which you would add support first: third-party libraries you will depend on, expected maintenance burden (based on the stability of the protocol and it's library), etc.
• You can use the Matterbridge API. This is a REST endpoint that is exposed by the Mattebridge binary, if configured to do so. You can then write your own independent binary / bot-client that "bridges" between the targeted chat protocol and Matterbridge. There are already a few of such third-party "plugins".

[qaisjp]

or could it have a form of a library loaded on runtime

This could be achieved using plugins: https://golang.org/pkg/plugin/

[jakubgs]

Thanks for the explanation, appreciate it.

I think I'd rather implement what you call "native support", but the Status protocol isn't stable enough yet to be included in your master. I think for now it would make more sense for us to try to implement support in a fork, and once the Protocol is stable enough we can try contributing a PR to master.

[jakubgs]

So, my understanding is that an implementation of a chat has to implement the Bridge interface: https://github.com/42wim/matterbridge/blob/942d8f1cedfb7325c0720f8967751bb1b77f5b82/bridge/bridge.go#L11-L16 One thing I'm was wondering about is how the plugin gets the configuration, but it appears the Bridge interface methods provide that already: https://github.com/42wim/matterbridge/blob/942d8f1cedfb7325c0720f8967751bb1b77f5b82/bridge/discord/discord.go#L54 https://github.com/42wim/matterbridge/blob/942d8f1cedfb7325c0720f8967751bb1b77f5b82/bridge/bridge.go#L98-L104 Other than that, is there anything else I should know?

[jakubgs]

One thing that makes me wonder is how MatterBridge gets messages from the channel.

I can see that Gitter bridge implements some kind of Go routine in JoinChannel that sends messages into a channel: https://github.com/42wim/matterbridge/blob/942d8f1cedfb7325c0720f8967751bb1b77f5b82/bridge/gitter/gitter.go#L69 But for example in Telegram module JoinChannel is empty: https://github.com/42wim/matterbridge/blob/942d8f1cedfb7325c0720f8967751bb1b77f5b82/bridge/telegram/telegram.go#L54-L56 So I'm not sure how this part works, maybe you can explain this to me?

[42wim]

https://github.com/42wim/matterbridge/wiki/Gateway:-developing-new-one is also a helpful page

@jakubgs regarding JoinChannel some protocols need to bot to be joined by the admin so they don't need or can't join the channel themselves.

Maybe the xmpp one is a bit simpeler: https://github.com/42wim/matterbridge/blob/942d8f1cedfb7325c0720f8967751bb1b77f5b82/bridge/xmpp/xmpp.go

Wrt how you get messages, most of the bridges run a for loop in a go routine on a successfull Connect() which receive the messages from the server and send them into matterbridge using the Remote message channel.

[jakubgs]

Perfect, thank you for the explanation. I will close it for now, and will eventually get back to you with a possible PR, but that might be a while before we consider our protocol libraries stable.

Cheers!