Matterbridge: IRC puppeting

[qaisjp]

This project looks amazing. I don't use this project yet. I currently have a custom setup for three-way bridging.

1. custom software for irc <-> discord
2. open-source bridge for slack <-> discord.

My custom bridge for Discord/IRC which has some advanced features, namely, dummy accounts! See qaisjp/go-discord-irc.

I'd like to merge this into matterbridge.

Features:

• There exists an IRC user per Discord user (name suffixed with ~d, likejohn~d`) (#361)
• Each IRC user has a unique hostname containing the Discord UID
  
  
  
  • It achieves this using WebIRC (requires special server tokens). See docs for WebIRC (_quick read_).
  
  
• IRC away status updates based on Discord status (#116)
• IRC user connects when Discord user comes "online" (or speaks whilst offline)
• IRC user disconnects from server after the Discord user is "offline" for a period of time (not just a period of general inactivity) (#654)
• PMing IRC users send PMs to Discord users (a special syntax is needed for Discord to IRC) (#191)
• Nickname mention conversions (mentioning qaisjp~d on IRC will convert to a correct @qaisjp on DIscord; mentioning @Some Weird Name on Discord will translate to Some_Weird_Name~d on IRC)
• IRC to Discord formatting conversions (inverse planned)
• Webhook support on Discord to have username/avatar spoofing (using instant automatically created webhooks)
  
  
  
  • uses avatar of a Discord user with the same name
  
  
  • planned: send Discord avatar to IRC (IRCv3)
  
  
• Live updates by editing the config file (partial) (#589)
• Discord message edits are transcribed as name~d meant to say "...."
• maybe some more?

I currently have two instances of go-discord-irc deployed to two IRC servers / discord guilds:

1. one with no custom config (so it has no spoofing, only one central listener user), and
2. one with custom config.

The one with custom config has the following features:

• IRC user per Discord member
• Server provides WebIRC credentials
• Server has a special username suffix: allows users with the same username, making all Discord users are suffixed with ~d, making
  
  
  
  • Note: ~ is ordinarily an illegal character, so this is a server with custom code
  
  
  • In my setup, Slack users don't appear as separate IRC users, they just appear as a Discord message from the central listener user)
  
  
  • If we supported multiple, it would be ~d, ~s, etc
  
  

This would also solve the several issues for IRC/Discord, at least when dummy user support is enabled (see list above with tagged issues).

Thoughts? I am happy to send pull requests to the project to make this a reality.

I would need: support from the community (i.e, coping with any questions I have whilst learning the codebase and implementing features).

The aim is to deprecate my project completely and for me to move completely to matterbridge.

[42wim]

I'd welcome support for this, but we have to do some changes to make this a reality.
At the moment, bridges aren't aware of users on other bridges, so this needs to be done first before we can integrate your irc spoofing feature

[patcon]

This all sounds super fucking rad @qaisjp! 🎉

It might take a bit to work through all these pieces as atomic feature requests, but my experience is that if you are patient in working things in, then others (incl myself in whatever way I can) would be really eager to support :)

[qaisjp]

Slowly but steadily we can make this happen! 🙂

[mithro]

This sounds super awesome and I would love to see it happen!

[qaisjp]

I've been looking into this, and I'm not sure what's the best way to go about this config-wise.

Example base config to work off

Take this simple bi-directional configuration that bridges between Discord and IRC.

[discord]
[discord.compsoc]
Token="<some value>"
Server="<some value>"
WebhookURL="<some value>"

[irc]
[irc.compsoc]
Server="localhost:6697"
Nick="DiscordBot"

[[gateway]]
name="compsoc.bottest"
enable=true

[[gateway.inout]]
account="irc.compsoc"
channel="#bottest"

[[gateway.inout]]
account="discord.compsoc"
channel="bottest"

Naming

Discord already support puppets, but they are... "ephemeral". We don't want to people to use a Puppets setting and realise they actually need to use WebhookURL. That can be considered poor user experience.

We know that Discord puppets are _not_ persistent, unlike IRC. So we could name our setting something like PersistentPuppets. Assuming that we set it to a boolean value... which we shouldn't, because....

Flow of knowledge

User information flows from discord to irc. How do we represent this information in the config?

And we probably want a configuration design that can gracefully support more than just IRC puppets.

Suggestion

What if we did something like this? I think including the term bridge might confuse people that are writing their config:

[[gateway]]
name="compsoc.bottest"
enable=true

[[gateway.bridge]]
account="irc.compsoc"
channel="#bottest"
chat="inout"
users="out"   # output

[[gateway.bridge]]
account="discord.compsoc"
channel="bottest"
chat="inout"
users="in"    # input

---

What do you think? How should this be designed? Please give me feedback! I want to know if there's a better way to design the config.

[poVoq]

Hmm, as for naming, I always considered the webhook method as user "spoofing" while what you are proposing for IRC seems to be proper user "puppeteering".

[qaisjp]

I only called it spoofing because when I wrote the issue I had not found a better word for it (which is 'puppeting')

[jlu5]

Hi all,

Lately I've been working on an alternative implementation that allows doing this in a stateless fashion. It involves an IRCd extension and a separate command to translate relayed messages into PRIVMSGs, and allows user spoofing in a way fairly similar to e.g. Discord webhooks. Although this limits the UI slightly (virtual users can't be DMed for example because they aren't actually connected), it simplifies how much state relay bots need to track.

I've tentatively placed the details in a repo: relaymsg.md. At least one IRCd vendor has shown interest in this, so I'm hoping to finalize a draft spec soon and send it to IRCv3 for consideration. See https://github.com/ircv3/ircv3-specifications/pull/417

[Justinzobel]

I'm running a private bridge just for myself to bridge three IRC rooms to private Telegram rooms. Is there a way I could have IRC PMs go to the bot's PM inside Telegram and responses like discussed above? ie user2@irc: Here's my reply to your PM.

[qaisjp]

I'm running a private bridge just for myself to bridge three IRC rooms to private Telegram rooms. Is there a way I could have IRC PMs go to the bot's PM inside Telegram and responses like discussed above? ie user2@irc: Here's my reply to your PM.

Not at the moment

[Justinzobel]

I'm not at my PC at the moment. Do private messages show up in the debug
log?

On Thu, 6 Aug 2020, 7:46 pm Qais Patankar, [e-mail] wrote:

I'm running a private bridge just for myself to bridge three IRC rooms to
private Telegram rooms. Is there a way I could have IRC PMs go to the bot's
PM inside Telegram and responses like discussed above? ie user2@irc:
Here's my reply to your PM.

Not at the moment

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/42wim/matterbridge/issues/667#issuecomment-669842253,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKOQBMEWE27AB7UGRW4YA3R7J7G5ANCNFSM4GMXSKNA
.

[westor7]

Will @qaisjp go-discord-irc be merged on @42wim matterbridge ? does it needs anything else to be finished?

This is a most-wanted merge :P i hope to be in the next version..

• Thanks!

[qaisjp]

I've slowly been adding some of the smaller features — the long term aim is to replace my bridge entirely with matterbridge, yes

[Mikaela]

I am not sure if this is the right place to ask, but are there any plans to support the RELAYMSG cap mentioned above (https://github.com/42wim/matterbridge/issues/667#issuecomment-634214165) or merging the support back to upstream Matterbridge?

I have been lately using a couple of Oragono based networks which would support it and make Matterbridge more pleasant to use on them.