doc: drop multi-upstream mode bits

doc/multi-upstream.md

@@ -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

doc/soju.1.scd

@@ -15,36 +15,29 @@ behalf of the user to provide extra features.
 
 - Multiple separate users sharing the same bouncer, each with their own
   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
   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
 the next connection. When registering or authenticating with NickServ, 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
 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
 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
 file when it receives the HUP signal. The configuration options _listen_, _db_
 and _log_ cannot be reloaded.