You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some matrix users are creating channels with only matrix users in them, with no IRC presence at all, but they are still being bridged. This creates an unnecessary amount of traffic on IRC. It would be better for the bridge to part all the users (except for 1) in these scenarios, and then re-join the users when a real IRC user joins the channel. When the bridge is in the process of joining/parting users, it should be marked as a "desynced" room, as such it requires #449. To prevent this being an attack vector (whereby 1 malicious IRC user repeatedly joins/parts a bridged channel) the joins/parts should be adequately rate-limited. A suggestion of 4 joins/parts per second has been proposed as adequate, but this needs to be configurable on a per-server basis.
This has been formally requested by Freenode.
The text was updated successfully, but these errors were encountered:
Some matrix users are creating channels with only matrix users in them, with no IRC presence at all, but they are still being bridged. This creates an unnecessary amount of traffic on IRC. It would be better for the bridge to part all the users (except for 1) in these scenarios, and then re-join the users when a real IRC user joins the channel. When the bridge is in the process of joining/parting users, it should be marked as a "desynced" room, as such it requires #449. To prevent this being an attack vector (whereby 1 malicious IRC user repeatedly joins/parts a bridged channel) the joins/parts should be adequately rate-limited. A suggestion of 4 joins/parts per second has been proposed as adequate, but this needs to be configurable on a per-server basis.
This has been formally requested by Freenode.
The text was updated successfully, but these errors were encountered: