~emersion/soju

ref: 0f6bac30b894b4a562f72ccffdaa0411b6ac74f3 soju/bridge.go -rw-r--r-- 2.3 KiB
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.
81c7e80e — Hubert Hirtz 1 year, 1 month ago
Forward RPL_TOPICWHOTIME to downstreams
Make length check clearer in sendNames
dc592636 — Hubert Hirtz 1 year, 3 months ago
Send compact channel name lists

This commit resolves `sendNames`' TODO.
Add support for multiple user channel memberships

User channel memberships are actually a set of memberships, not a single
value. This introduces memberships, a type representing a set of
memberships, stored as an array of memberships ordered by descending
rank.

This also adds multi-prefix to the permanent downstream and upstream
capabilities, so that we try to get all possible channel memberships.
Make downstreamConn.marshal{Entity,UserPrefix} take a network

This will be used when sending history while upstream is disconnected.
Kill downstreamConn.marshal{Nick,Channel}

We can just use downstreamConn.marshalEntity instead.
Add downstream TOPIC support
Add downstream NAMES support

NAMES reply for channels currently joined will be returned from cache;
requests for channels not joined will be forwarded from upstream.
Add MODE arguments support

- Add RPL_ISUPPORT support with CHANMODES, CHANTYPES, PREFIX parsing
- Add support for channel mode state with mode arguments
- Add upstream support for RPL_UMODEIS, RPL_CHANNELMODEIS
- Request channel MODE on upstream channel JOIN
- Use sane default channel mode and channel mode types
Avoid sending JOIN twice for the same channel
Rename project to soju
Add functions to translate between upstream and downstream names
Don't write to downstreamConn.messages directly

Use a helper function instead. This will allow us to change
downstreamConn implementation details without having to update the whole
codebase.
Add missing bridge.go, oops