To do puppeteering on the IRC side, j2i uses RELAYMSG or falls back to relaying messages as the bridge bot. Most IRC networks still don't support RELAYMSG, and having the bridge bot itself relay messages is ugly and inconvenient. A new option could be added where puppets are connected as separate nicks to a network.
I did plan to add this before, but I chose not to because:
I primarily use j2i on my own IRC network which supports RELAYMSG
Having lots of TCP connections open to an IRC server probably wouldn't scale too well
To do puppeteering on the IRC side, j2i uses RELAYMSG or falls back to relaying messages as the bridge bot. Most IRC networks still don't support RELAYMSG, and having the bridge bot itself relay messages is ugly and inconvenient. A new option could be added where puppets are connected as separate nicks to a network.
I did plan to add this before, but I chose not to because:
1. I primarily use j2i on my own IRC network which supports RELAYMSG
2. Having lots of TCP connections open to an IRC server probably wouldn't scale too well
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
To do puppeteering on the IRC side, j2i uses RELAYMSG or falls back to relaying messages as the bridge bot. Most IRC networks still don't support RELAYMSG, and having the bridge bot itself relay messages is ugly and inconvenient. A new option could be added where puppets are connected as separate nicks to a network.
I did plan to add this before, but I chose not to because:
As an upside though, bridging certain interactions bidirectionally would finally become possible to do cleanly, such as reactions.