Does matterbridge support "puppet" mode style of relaying?

[mithro]

I was wondering if matterbridge supported a feature which is normally called something like "puppet" mode?

This is were instead of having a single robot which just includes the relevant nick in the message, instead for every user on one side of the bridge, a separate "puppet" is created on the other side. See an example of this at https://github.com/qaisjp/go-discord-irc and a video example in their README;

This functionally means that features like nick tab completion works and makes it very easy to make direct messages and other similar "advanced" functionality work.

I couldn't find anything about this type of feature after quickly skimming the documentation.

[qaisjp]

Not at the moment.

There is a stateless implementation here which uses the RELAYMSG cap, and only seems to work on these servers.

It makes messages show up with the correct username on IRC (webhook-style), but does not populate the list of users, and therefore doesn't have the nick completion feature.

In the very long term I'm working on #667, which intends to bring this to matterbridge in a generic manner, that supports multiple bridges (and not necessarily just Discord).

My approach to this is by slowly rearchitecting go-discord-irc into individual packages and components, so that those individual features can slowly be brought to matterbridge.

One example of this would be the "transmitter" interface, which brings some of the Discord webhooks management from my go-discord-irc into matterbridge. This is what the changes were on the matterbridge side, and now go-discord-irc uses matterbridge's transmitter instead of its own.

The next step that I am currently working on is creating a generic package to handle IRC puppet management. The main goal of this generic package is to support connecting to a separate service that maintains the IRC connections, so that a simple restart of the bridge does not sending hundreds of IRC joinquit messages.

After some discussion about the implementation here, I have completed an intermediate implementation which works! The next step of that implementation is here. There are a few more milestones left for that package.

At the very least, this package would make an MVP for IRC puppeting possible. The harder thing is create a generic (multi-bridge) interface for determining when new IRC users should be created, handling nick conflicts, etc. (Without adding special IRC behaviour to each source bridge!)

I'm happy to answer any questions you have!

---

Is it reasonable to close this issue as a possible duplicate #667?

[mithro]

@qaisjp - Happy for you to do whatever you think is best. It is awesome that you are working on this, is there any way to provide you with more support? (I don't have time to help with development, but could help with PR or potential sponsorship?)