~emersion/soju

ref: cacbd4894902833fff024e2e51d7d0ec42ad5926 soju/upstream.go -rw-r--r-- 46.5 KiB
Forward user mode changes in single-upstream mode

References: https://todo.sr.ht/~emersion/soju/20
Forward MOTD messages downstream

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.
Add support for IRCv3 setname

References: https://todo.sr.ht/~emersion/soju/41
Don't forward label tags

We don't want to have the label tag when calling uc.produce, otherwise
downstream will end up with junk labels.
Drop TAGMSG in detached channels

- 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.
Add user prefix to upstream logger
Relay detached channel backlog as BouncerServ NOTICE if necessary

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
Move isHighlight to irc.go
Save delivery receipts in DB

This avoids loosing history on restart for clients that don't
support chathistory.

Closes: https://todo.sr.ht/~emersion/soju/80
Rename user.clients to clientNames

This doesn't contain anything other than just the names. Make this
clearer.
Make NickServ detection casemapping-aware
Introduce deliveredStore

This hides the double-map complexity behind a dedicated type.
Move network.clients to user

No need to have this list per-network.
Simplify network.offlineClients

Replace it with a list of all clients (online or offline).
Introduce deliveredClientMap

Adds more semantics to map[string]string. Simplifies the complicated
mapStringStringCasemapMap type.
Implement casemapping

TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)

== What is casemapping? ==

see <https://modern.ircdocs.horse/#casemapping-parameter>

== Casemapping and multi-upstream ==

Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],

1. soju must also update the database accordingly to upstreams'
   casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
   that is a subset of all supported casemappings (here, ascii).

[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.

Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.

downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.

Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).

== Message forwarding and casemapping ==

downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user.  This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).

marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters.  ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).

== Casemapping changes ==

Casemapping changes are not fully supported by this patch and will
result in loss of history.  This is a limitation of the protocol and
should be solved by the RENAME spec.
Don't update downstream caps in upstream RPL_WELCOME handler

Prior to being registered, upstreamConn.handleMessage doesn't run
in the user goroutine, it runs in a goroutine specific to the
network. Thus we shouldn't access any user data structure from
there.

downstreamConn.updateSupportedCaps is already called from the
eventUpstreamConnected handler in user.run, the call being removed
was unnecessary.

Closes: https://todo.sr.ht/~emersion/soju/108
Don't store history for NickServ

Closes: https://todo.sr.ht/~emersion/soju/104
Passthrough some ISUPPORT tokens
Properly handle all ISUPPORT negations
Next