Nothing in the IRC backend knows what a bouncer is - no soju.im/bouncer-networks, no
ZNC network handling.
Somebody running soju or ZNC in front of several networks connects once and gets all of
them, but moho draws a single server buffer with every channel from every network in it,
and no way to tell which channel belongs where. Two networks with a #general are
indistinguishable.
The capability lets a client enumerate the bouncer's networks and bind a connection to
one, which is what turns that single buffer back into the several it should be.
Nothing in the IRC backend knows what a bouncer is - no `soju.im/bouncer-networks`, no
ZNC network handling.
Somebody running soju or ZNC in front of several networks connects once and gets all of
them, but moho draws a single server buffer with every channel from every network in it,
and no way to tell which channel belongs where. Two networks with a `#general` are
indistinguishable.
The capability lets a client enumerate the bouncer's networks and bind a connection to
one, which is what turns that single buffer back into the several it should be.
This was filed on a premise that does not hold up, and the correction is worth
recording so it is not re-filed later.
The extension is soju-specific.soju.im/bouncer-networks is exactly what the
vendor prefix says it is. ZNC - by a wide margin the most deployed IRC bouncer - does
not implement it. So this only ever applied to people running soju.
The problem it describes is already solved. The issue claims a bouncer's networks
"all arrive as one server" with "no way to tell which channel belongs where". That is
only true of a bare username, which is not how any bouncer's documentation tells you to
connect. The user/network convention works in moho today, and was checked rather than
assumed:
username goes into the USER command verbatim (nobilis/src/backend/irc/connect.rs:754)
sasl_user is used verbatim for SASL (nobilis/src/backend/irc/sasl.rs:469)
the accounts panel exposes the SASL username as an editable field
One moho account per network, each binding to the right one, works now with no code at
all.
So the real gap was never capability, only auto-discovery: enumerating the networks
instead of adding each account by hand once. That is a few minutes of one-time setup,
for the intersection of runs soju specifically and is bothered by doing it manually.
Against that: it is the only one of the four IRC items that needs client work as well as
daemon work, and it would add a discovery path, a bind step and a network list to carry
forever. That is real maintenance assumed on behalf of an edge case, and the trade is
not worth it.
Reopen if soju's share changes, or if the extension is ever adopted beyond it.
Closing as won't implement.
This was filed on a premise that does not hold up, and the correction is worth
recording so it is not re-filed later.
**The extension is soju-specific.** `soju.im/bouncer-networks` is exactly what the
vendor prefix says it is. ZNC - by a wide margin the most deployed IRC bouncer - does
not implement it. So this only ever applied to people running soju.
**The problem it describes is already solved.** The issue claims a bouncer's networks
"all arrive as one server" with "no way to tell which channel belongs where". That is
only true of a bare username, which is not how any bouncer's documentation tells you to
connect. The `user/network` convention works in moho today, and was checked rather than
assumed:
- `username` goes into the `USER` command verbatim (`nobilis/src/backend/irc/connect.rs:754`)
- `sasl_user` is used verbatim for SASL (`nobilis/src/backend/irc/sasl.rs:469`)
- the accounts panel exposes the SASL username as an editable field
One moho account per network, each binding to the right one, works now with no code at
all.
So the real gap was never capability, only auto-discovery: enumerating the networks
instead of adding each account by hand once. That is a few minutes of one-time setup,
for the intersection of *runs soju specifically* and *is bothered by doing it manually*.
Against that: it is the only one of the four IRC items that needs client work as well as
daemon work, and it would add a discovery path, a bind step and a network list to carry
forever. That is real maintenance assumed on behalf of an edge case, and the trade is
not worth it.
Reopen if soju's share changes, or if the extension is ever adopted beyond it.
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.
Nothing in the IRC backend knows what a bouncer is - no
soju.im/bouncer-networks, noZNC network handling.
Somebody running soju or ZNC in front of several networks connects once and gets all of
them, but moho draws a single server buffer with every channel from every network in it,
and no way to tell which channel belongs where. Two networks with a
#generalareindistinguishable.
The capability lets a client enumerate the bouncer's networks and bind a connection to
one, which is what turns that single buffer back into the several it should be.
Closing as won't implement.
This was filed on a premise that does not hold up, and the correction is worth
recording so it is not re-filed later.
The extension is soju-specific.
soju.im/bouncer-networksis exactly what thevendor prefix says it is. ZNC - by a wide margin the most deployed IRC bouncer - does
not implement it. So this only ever applied to people running soju.
The problem it describes is already solved. The issue claims a bouncer's networks
"all arrive as one server" with "no way to tell which channel belongs where". That is
only true of a bare username, which is not how any bouncer's documentation tells you to
connect. The
user/networkconvention works in moho today, and was checked rather thanassumed:
usernamegoes into theUSERcommand verbatim (nobilis/src/backend/irc/connect.rs:754)sasl_useris used verbatim for SASL (nobilis/src/backend/irc/sasl.rs:469)One moho account per network, each binding to the right one, works now with no code at
all.
So the real gap was never capability, only auto-discovery: enumerating the networks
instead of adding each account by hand once. That is a few minutes of one-time setup,
for the intersection of runs soju specifically and is bothered by doing it manually.
Against that: it is the only one of the four IRC items that needs client work as well as
daemon work, and it would add a discovery path, a bind step and a network list to carry
forever. That is real maintenance assumed on behalf of an edge case, and the trade is
not worth it.
Reopen if soju's share changes, or if the extension is ever adopted beyond it.