The user.updateNetwork function is a bit involved because we need to
make sure that the upstream connection is closed before re-connecting
(would otherwise cause "Nick already used" errors) and that the
downstream connections' state is kept in sync.
References: https://todo.sr.ht/~emersion/soju/17
Some servers do not support TLS, or have invalid, expired or self-signed
TLS certificates. While the right fix would be toi contact each server
owner to add support for valid TLS, supporting plaintext upstream
connections is sometimes necessary.
This adds support for the irc+insecure address scheme, which connects to
a network in plain-text over TCP.
This is preparatory work for adding other connection types to upstream
servers. The service command `network create` now accepts a scheme in
the address flag, which specifies how to connect to the upstream server.
The only supported scheme for now is ircs, which is also the default if
no scheme is specified. ircs connects to a network over a TLS TCP
connection.
Some servers use custom IRC bots with custom commands for registering to
specific services after connection.
This adds support for setting custom raw IRC messages, that will be
sent after registering to a network.
It also adds support for a custom flag.Value type for string
slice flags (flags taking several string values).
On some IRC clients, NOTICE messages from a user which does not have a
user or host in its prefix (and therefore only have a Name, and look
like prefixes of servers), are treated as server notices rather than
user notices, and are treated differently. (For that matter, soju also
considers NOTICE messages from users with only a Name in their prefix as
special server messages). On most of these clients, NOTICE messages from
a user are formatted differently and stand out from the large flow of
incoming misceallenous server messages.
This fills the service user with fake User and Host values so that
NOTICE messages from it correctly appear as coming from a user. This
is particularly useful in the context of connection and disconnect
errors NOTICE messages that are broadcast from the service user to all
relevant downstreams.
This adds support for sending the exact error message of a network when
it is disconnected, in the reply to the service command `network
status`. This lets users easily examine why a network is currently
disconnected.
No lock is needed because all reads and writes of network.lastError are
made in the user goroutine.
Closes: https://todo.sr.ht/~emersion/soju/28
In order to notify the user when we are disconnected from a network
(either due to an error, or due a QUIT), and when we fail reconnecting,
this commit adds support for sending a short NOTICE message from the
service user to all relevant downstreams.
The last error is stored, and cleared on successful connection, to
ensure that the user is *not* flooded with identical connection error
messages, which can often happen when a server is down.
No lock is needed on lastError because it is only read and modified from
the user goroutine.
Closes: https://todo.sr.ht/~emersion/soju/27
