On upstreams without message-tags support, we do not advertise
message-tags anymore. Still, we want to send the batch tag when the
client explicitly requested it.
This fixes a critical issue where we drop the batch tag on chathistory
messages for upstreams that do not support message-tags.
Previously, we would always advertise mesasge-tags. This made
downstreams believe they could send TAGMSG to the upstream, even though
the upstream did not support it.
This adds support for upstream echo-message. This capability is
enabled when the upstream supports labeled-response.
When it is enabled, we don't echo downstream messages in the downstream
handler, but rather wait for the upstream to echo it, to produce it to
downstreams.
When it is disabled, we keep the same behaviour as before: produce the
message to all downstreams as soon as it is received from the
downstream.
In other words, the main functional difference is that when the upstream
supports labeled-response, the client will now receive an echo for its
messages when the server acknowledges them, rather than when soju acks
them.
Additionally, uc.produce was refactored to take an ID rather than a
downstream.
When a client sends BOUNCER CHANGENETWORK with no value (or an empty
port value), this means it wants to reset the port value to its default
value.
Previously we considered an empty port as an actual valid, empty port
value, which would then be used to connect to the server (dial
'example.com:' (ie 'example.com:0'), which failed.
This avoids having more than one in flight at a time (avoids
hitting rate limits a bit) and routes back replies to the correct
downstream connection (even if labeled-response isn't supported).
Closes: https://todo.sr.ht/~emersion/soju/193
Just force-set the nickname and completely disregard what the client
sets during connection registration. Clients must discover their
effective nickname via RPL_WELCOME.
Most users will connect to their server with `<username>` as their
username in order to configure their upstreams.
Multi-upstream can be unintuitive to them and should not be enabled on
that first connection that is usually used for upstream configuration.
Multi-upstream is instead a power-user feature that should be explicitly
enabled with a specific network suffix.
We reserve the network suffix `*` and use it a special case to mean that
it requests multi-upstream mode.
Previously, when we sent READ for an upstream which was disconnected,
we would fail with an error. This is because we called unmarshalEntity,
which checked that the upstream was in the connected status.
But we don't need to be connected to update the READ timestamp, this is
a purely offline (wrt the upstream) operation.
This simply switches the call from unmarshalEntity to
unmarshalEntityNetwork to fix the issue.
When the client supports draft/chathistory, no need to request
delivery receipts via PING messages. Let's just not leave delivery
receipts alone. They'll go stale but should be never used (or used
by a non-chathistory client).
READ lets downstream clients share information between each other about
what messages have been read by other downstreams.
Each target/entity has an optional corresponding read receipt, which is
stored as a timestamp.
- When a downstream sends:
READ #chan timestamp=2020-01-01T01:23:45.000Z
the read receipt for that target is set to that date
- soju sends READ to downstreams:
- on JOIN, if the client uses the soju.im/read capability
- when the read receipt timestamp is set by any downstream
The read receipt date is clamped by the previous receipt date and the
current time.
A previous fix (d4b7bb02da) only fixed sending echo-message for
TAGMSG to self. We also need to send echo-message for TAGMSG to
other targets.
Closes: https://todo.sr.ht/~emersion/soju/111
Once the downstream connection has logged in with their bouncer
credentials, allow them to issue more SASL auths which will be
redirected to the upstream network. This allows downstream clients
to provide UIs to login to transparently login to upstream networks.
Implements the following recommendation from the spec:
> If the client completes registration (with CAP END, NICK, USER and any other
> necessary messages) while the SASL authentication is still in progress, the
> server SHOULD abort it and send a 906 numeric, then register the client
> without authentication.
The MOTD indicates the end of the registration's message burst, and
the server can send arbitrary messages before it.
Update the supported capabilities, the nick and the realname before
MOTD to make it so client logic that runs on MOTD can work with
up-to-date info.
This function wraps a parent context, and returns a new context
cancelled when the connection is closed. This will make it so
operations started from downstreamConn.handleMessage will be
cancelled when the connection is closed.
As a bonus, the timeout now applies to the whole TLS dial
operation. Before the timeout only applied to the net dial
operation, making it possible for a bad server to stall the request
by making the TLS handshake extremely slow.
When on an unbound bouncer network downstream, we should return no
targets (there are none, because there are no upstreams at all).
When on a multi-upstream downstream, we should return no targets as we
don't support multi-upstream CHATHISTORY TARGETS.
Before this patch, we returned a misleading error message:
:example.com 403 :Missing network suffix in name
If a downstream of prefix host `foo` sends a message, the other
downstream of prefix host `bar` should receive an echo PRIVMSG with
prefix host bar.
This fixes a regression where no prefix host was sent at all.
Add support for MONITOR in single-upstream mode.
Each downstream has its own set of monitored targets. These sets
are merged together to compute the MONITOR commands to send to
upstream.
Each upstream has a set of monitored targets accepted by the server
alongside with their status (online/offline). This is used to
directly send replies to downstreams adding a target another
downstream has already added, and send MONITOR S[TATUS] replies.
Co-authored-by: delthas <delthas@dille.cc>
