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
We were doing some things wrong here, e.g. not sending echo messages
for NOTICE.
git-svn-id: file:///srv/svn/repo/suika/trunk@562 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
And add the prefix throughout the spec, to make it clear the unprefixed
version is not to be used.
git-svn-id: file:///srv/svn/repo/suika/trunk@537 f0ae65fe-ee39-954e-97ec-027ff2717ef4
In multi-upstream mode, we can't relay WHO/WHOIS messages for the
current user, because we can't decide which upstream server the
message should be relayed to.
In single-upstream server, we do know which upstream server to use,
so we can just blindly relay the message.
This allows users to send a self-WHO/WHOIS to check their cloak and
other information.
git-svn-id: file:///srv/svn/repo/suika/trunk@520 f0ae65fe-ee39-954e-97ec-027ff2717ef4
The NICK must only apply to the specific network, not to the downstream
connection.
git-svn-id: file:///srv/svn/repo/suika/trunk@512 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
This allows to have shorter and more future-proof IDs. This also
guarantees the IDs will only use reasonable ASCII characters (no
spaces), removing the need to encode them for PING/PONG tokens.
git-svn-id: file:///srv/svn/repo/suika/trunk@488 f0ae65fe-ee39-954e-97ec-027ff2717ef4
messageStore isn't aware of the network's case-mapping. We need
to canonicalize the names before passing them to messageStore.
git-svn-id: file:///srv/svn/repo/suika/trunk@484 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Adds more semantics to map[string]string. Simplifies the complicated
mapStringStringCasemapMap type.
git-svn-id: file:///srv/svn/repo/suika/trunk@480 f0ae65fe-ee39-954e-97ec-027ff2717ef4
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.
git-svn-id: file:///srv/svn/repo/suika/trunk@478 f0ae65fe-ee39-954e-97ec-027ff2717ef4
... and do not forward INVITEs to downstreams that do not support the
capability.
The downstream capability can be permanent because there is no way for a
client to get the list of people invited to a channel, thus no state can
be corrupted.
git-svn-id: file:///srv/svn/repo/suika/trunk@448 f0ae65fe-ee39-954e-97ec-027ff2717ef4
