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.
git-svn-id: file:///srv/svn/repo/suika/trunk@781 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This param doesn't contain modes, it contains user flags (such as
H/G for away status).
git-svn-id: file:///srv/svn/repo/suika/trunk@779 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This avoids blocking on upstream message rate limiting for too
long.
git-svn-id: file:///srv/svn/repo/suika/trunk@757 f0ae65fe-ee39-954e-97ec-027ff2717ef4
It's extra code for something clients should ignore because it's
unreliable and useless.
git-svn-id: file:///srv/svn/repo/suika/trunk@745 f0ae65fe-ee39-954e-97ec-027ff2717ef4
If the nickname we want is taken, fallback to another one by
appending underscores. Use MONITOR to figure out when we can request
our desired nick again.
Closes: https://todo.sr.ht/~emersion/soju/35
git-svn-id: file:///srv/svn/repo/suika/trunk@743 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Clients aren't supposed to do this, but in case they do, let's
send them an error.
git-svn-id: file:///srv/svn/repo/suika/trunk@742 f0ae65fe-ee39-954e-97ec-027ff2717ef4
If a client queues a high number of commands and then disconnects,
remove all of the pending commands. This avoids unnecessarily
sending commands whose results won't be used.
git-svn-id: file:///srv/svn/repo/suika/trunk@738 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This adds support for the draft/account-registration extension [1].
This allows downstreams to register on upstream networks.
[1]: https://ircv3.net/specs/extensions/account-registration
git-svn-id: file:///srv/svn/repo/suika/trunk@729 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This will stop clients from trying to issue AUTHENTICATE requests
after connection registration.
git-svn-id: file:///srv/svn/repo/suika/trunk@725 f0ae65fe-ee39-954e-97ec-027ff2717ef4
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.
git-svn-id: file:///srv/svn/repo/suika/trunk@724 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This will allow clients to properly show/hide UI to login and
register.
git-svn-id: file:///srv/svn/repo/suika/trunk@722 f0ae65fe-ee39-954e-97ec-027ff2717ef4
The new upstream-user-ip directive allows bouncer operators to
assign one IP address per user.
git-svn-id: file:///srv/svn/repo/suika/trunk@705 f0ae65fe-ee39-954e-97ec-027ff2717ef4
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>
git-svn-id: file:///srv/svn/repo/suika/trunk@684 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This has the following upsides:
- We can now routes WHO replies to the correct client, without
broadcasting them to everybody.
- We are less likely to hit server rate limits when multiple downstreams
are issuing WHO commands at the same time.
git-svn-id: file:///srv/svn/repo/suika/trunk@682 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Multi-upstream connections can still send LIST commands with a
network suffix.
git-svn-id: file:///srv/svn/repo/suika/trunk@681 f0ae65fe-ee39-954e-97ec-027ff2717ef4
The message stores don't need to access the internal network
struct, they just need network metadata such as ID and name.
This can ease moving message stores into a separate package in the
future.
git-svn-id: file:///srv/svn/repo/suika/trunk@666 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Make Network.Nick optional, default to the user's username. This
will allow adding a global setting to set the nickname in the
future, just like we have for the real name.
References: https://todo.sr.ht/~emersion/soju/110
git-svn-id: file:///srv/svn/repo/suika/trunk@664 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This adds support for WHOX, without bothering about flags and mask2
because Solanum and Ergo [1] don't support it either.
The motivation is to allow clients to reliably query account names.
It's not possible to use WHOX tokens to route replies to the right
client, because RPL_ENDOFWHO doesn't contain it.
[1]: https://github.com/ergochat/ergo/pull/1184
Closes: https://todo.sr.ht/~emersion/soju/135
git-svn-id: file:///srv/svn/repo/suika/trunk@660 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This is a mecanical change, which just lifts up the context.TODO()
calls from inside the DB implementations to the callers.
Future work involves properly wiring up the contexts when it makes
sense.
git-svn-id: file:///srv/svn/repo/suika/trunk@652 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This allows users to set a default realname used if the per-network
realname isn't set.
A new "user update" command is introduced and can be extended to edit
other user properties and other users in the future.
git-svn-id: file:///srv/svn/repo/suika/trunk@568 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Typically done via:
/notice $<bouncer> <message>
Or, for a connection not bound to a specific network:
/notice $* <message>
The message is broadcast as BouncerServ, because that's the only
user that can be trusted to belong to the bouncer by users. Any
other prefix would conflict with the upstream network.
git-svn-id: file:///srv/svn/repo/suika/trunk@563 f0ae65fe-ee39-954e-97ec-027ff2717ef4
The first MOTD upon connection is ignored, but subsequent MOTD messages
(requested by the "MOTD" message from the client, typically using a
/motd command) are forwarded.
git-svn-id: file:///srv/svn/repo/suika/trunk@552 f0ae65fe-ee39-954e-97ec-027ff2717ef4
We don't want to have the label tag when calling uc.produce, otherwise
downstream will end up with junk labels.
git-svn-id: file:///srv/svn/repo/suika/trunk@526 f0ae65fe-ee39-954e-97ec-027ff2717ef4
- Do not relay TAGMSG as notices,
- Do not reattach when a TAGMSG is received,
- Do not reset the detach timer when a TAGMSG is received.
git-svn-id: file:///srv/svn/repo/suika/trunk@505 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Instead of ignoring detached channels wehn replaying backlog,
process them as usual and relay messages as BouncerServ NOTICEs
if necessary. Advance the delivery receipts as if the channel was
attached.
Closes: https://todo.sr.ht/~emersion/soju/98
git-svn-id: file:///srv/svn/repo/suika/trunk@499 f0ae65fe-ee39-954e-97ec-027ff2717ef4
