doc: drop multi-upstream mode bits
This commit is contained in:
parent
f646dc9ff2
commit
085f5c17a4
@ -1,29 +0,0 @@
|
|||||||
# Multi-upstream mode
|
|
||||||
|
|
||||||
When setting up a new IRC client which doesn't support the
|
|
||||||
`soju.im/bouncer-networks` extension, one needs to configure as many servers as
|
|
||||||
there are networks configured in soju. Whenever a network is added or removed
|
|
||||||
from the soju configuration, all client configurations also need to be updated
|
|
||||||
accordingly. This can be cumbersome especially when dealing with many clients.
|
|
||||||
|
|
||||||
To address this issue, soju supports a _multi-upstream mode_. Instead of
|
|
||||||
configuring multiple servers in the client, only one connection to the bouncer
|
|
||||||
is required. soju will expose all channels and users from all configured
|
|
||||||
networks on this single connection. Channel names and nicknames will be suffixed
|
|
||||||
with the network name. For instance, the `#soju` channel will appear with the
|
|
||||||
name `#soju/libera`, and to talk to `emersion` on OFTC one would need to send a
|
|
||||||
message to `emersion/oftc`. The special `BouncerServ` service won't have a
|
|
||||||
suffix.
|
|
||||||
|
|
||||||
To enable this mode, connect to the bouncer with the username
|
|
||||||
`<soju username>/*`.
|
|
||||||
|
|
||||||
To add a new network, send messages to `BouncerServ`, for instance:
|
|
||||||
|
|
||||||
/msg BouncerServ network create -addr irc.libera.chat -name libera
|
|
||||||
|
|
||||||
To join a channel or message a user, remember to use the correct suffix, for
|
|
||||||
instance:
|
|
||||||
|
|
||||||
/join #soju/libera
|
|
||||||
/query emersion/libera
|
|
@ -15,36 +15,29 @@ behalf of the user to provide extra features.
|
|||||||
|
|
||||||
- Multiple separate users sharing the same bouncer, each with their own
|
- Multiple separate users sharing the same bouncer, each with their own
|
||||||
upstream servers
|
upstream servers
|
||||||
- Clients connecting to multiple upstream servers via a single connection to
|
|
||||||
the bouncer
|
|
||||||
- Sending the backlog (messages received while the user was disconnected from
|
- Sending the backlog (messages received while the user was disconnected from
|
||||||
the bouncer), with per-client buffers
|
the bouncer), with per-client buffers
|
||||||
|
|
||||||
|
To connect to the bouncer, use the bouncer username and password. To use a
|
||||||
|
client which doesn't support the _soju.im/bouncer-networks_ IRC extension,
|
||||||
|
setup one connection per server configured in soju, and indicate the network
|
||||||
|
name in the username: "<username>/<network>". Then channels can be joined and
|
||||||
|
parted as if you were directly connected to the upstream server.
|
||||||
|
|
||||||
|
For per-client history to work, clients need to indicate their name. This can
|
||||||
|
be done by adding a "@<client>" suffix to the username.
|
||||||
When joining a channel, the channel will be saved and automatically joined on
|
When joining a channel, the channel will be saved and automatically joined on
|
||||||
the next connection. When registering or authenticating with NickServ, the
|
the next connection. When registering or authenticating with NickServ, the
|
||||||
credentials will be saved and automatically used on the next connection if the
|
credentials will be saved and automatically used on the next connection if the
|
||||||
server supports SASL. When parting a channel with the reason "detach", the
|
server supports SASL. When parting a channel with the reason "detach", the
|
||||||
channel will be detached instead of being left.
|
channel will be detached instead of being left.
|
||||||
|
|
||||||
|
If a network specified in the username doesn't exist, and the network name is a
|
||||||
|
valid hostname, the network will be automatically added.
|
||||||
|
|
||||||
When all clients are disconnected from the bouncer, the user is automatically
|
When all clients are disconnected from the bouncer, the user is automatically
|
||||||
marked as away.
|
marked as away.
|
||||||
|
|
||||||
soju supports two connection modes:
|
|
||||||
|
|
||||||
- Single upstream mode: one downstream connection maps to one upstream
|
|
||||||
connection. To enable this mode, connect to the bouncer with the username
|
|
||||||
"<username>/<network>". If the bouncer isn't connected to the upstream
|
|
||||||
server, it will get automatically added. Then channels can be joined and
|
|
||||||
parted as if you were directly connected to the upstream server.
|
|
||||||
- Multiple upstream mode: one downstream connection maps to multiple upstream
|
|
||||||
connections. Channels and nicks are suffixed with the network name. To join
|
|
||||||
a channel, you need to use the suffix too: _/join #channel/network_. Same
|
|
||||||
applies to messages sent to users. To enable this mode, connect to the bouncer
|
|
||||||
with the username "<username>/\*".
|
|
||||||
|
|
||||||
For per-client history to work, clients need to indicate their name. This can
|
|
||||||
be done by adding a "@<client>" suffix to the username.
|
|
||||||
|
|
||||||
soju will reload the configuration file, the TLS certificate/key and the MOTD
|
soju will reload the configuration file, the TLS certificate/key and the MOTD
|
||||||
file when it receives the HUP signal. The configuration options _listen_, _db_
|
file when it receives the HUP signal. The configuration options _listen_, _db_
|
||||||
and _log_ cannot be reloaded.
|
and _log_ cannot be reloaded.
|
||||||
|
Loading…
Reference in New Issue
Block a user