Unify updatePassword and updateRealname into a single function. This
allows "user update" to be atomic.
git-svn-id: file:///srv/svn/repo/suika/trunk@572 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
We weren't sending them to downstreams which weren't bound to a
network.
git-svn-id: file:///srv/svn/repo/suika/trunk@543 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 avoids loosing history on restart for clients that don't
support chathistory.
Closes: https://todo.sr.ht/~emersion/soju/80
git-svn-id: file:///srv/svn/repo/suika/trunk@489 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This doesn't contain anything other than just the names. Make this
clearer.
git-svn-id: file:///srv/svn/repo/suika/trunk@487 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
No need to attempt to send backlog for all targets in the network.
We're only interested in a single channel.
git-svn-id: file:///srv/svn/repo/suika/trunk@453 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Uses an in-memory ring buffer.
Closes: https://todo.sr.ht/~emersion/soju/96
git-svn-id: file:///srv/svn/repo/suika/trunk@442 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This allows for other implementations that aren't based on a filesystem.
git-svn-id: file:///srv/svn/repo/suika/trunk@439 f0ae65fe-ee39-954e-97ec-027ff2717ef4
... so that the JOIN/history batch takes into account all capabilities.
Without this commit for example, enabling multi-prefix after the batch
makes the client send NAMES requests for all channels, which generate
needless traffic.
git-svn-id: file:///srv/svn/repo/suika/trunk@437 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This uses the fields added previously to the Channel struct to implement
the actual detaching/reattaching/relaying logic.
The `FilterDefault` values of the messages filters are currently
hardcoded.
The values of the message filters are not currently user-settable.
This introduces a new user event, eventChannelDetach, which stores an
upstreamConn (which might become invalid at the time of processing), and
a channel name, used for auto-detaching. Every time the channel detach
timer is refreshed (by receveing a message, etc.), a new timer is
created on the upstreamChannel, which will dispatch this event after the
duration (and discards the previous timer, if any).
git-svn-id: file:///srv/svn/repo/suika/trunk@435 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Introduce a messageStore type, which will allow for multiple
implementations (e.g. in the DB or in-memory instead of on-disk).
The message store is per-user so that we don't need to deal with locking
and it's easier to implement per-user limits.
git-svn-id: file:///srv/svn/repo/suika/trunk@423 f0ae65fe-ee39-954e-97ec-027ff2717ef4
This commit changes the Network schema to use user IDs instead of
usernames. While at it, a new UNIQUE(user, name) constraint ensures
there is no conflict with custom network names.
Closes: https://todo.sr.ht/~emersion/soju/86
References: https://todo.sr.ht/~emersion/soju/29
git-svn-id: file:///srv/svn/repo/suika/trunk@421 f0ae65fe-ee39-954e-97ec-027ff2717ef4
... to allow the caller to correctly do any necessary casemapping.
git-svn-id: file:///srv/svn/repo/suika/trunk@416 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Instead, always read chat history from logs. Unify the implicit chat
history (pushing history to clients) and explicit chat history
(via the CHATHISTORY command).
Instead of keeping track of ring buffer cursors for each client, use
message IDs.
If necessary, the ring buffer could be re-introduced behind a
common MessageStore interface (could be useful when on-disk logs are
disabled).
References: https://todo.sr.ht/~emersion/soju/80
git-svn-id: file:///srv/svn/repo/suika/trunk@409 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Keep the ring buffer alive even if all clients are connected. Keep the
ID of the latest delivered message even for online clients.
As-is, this is a net downgrade: memory usage increases because ring
buffers aren't free'd anymore. However upcoming commits will replace the
ring buffer with log files. This change makes reading from log files
easier.
git-svn-id: file:///srv/svn/repo/suika/trunk@406 f0ae65fe-ee39-954e-97ec-027ff2717ef4
- Don't print the raw IRC message, since we already show the original
error message
- Avoid double-printing "registration failed"
git-svn-id: file:///srv/svn/repo/suika/trunk@399 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Allow up to 10 outgoing messages in a burst, then throttle to 1 message
each 2 seconds.
Closes: https://todo.sr.ht/~emersion/soju/87
git-svn-id: file:///srv/svn/repo/suika/trunk@398 f0ae65fe-ee39-954e-97ec-027ff2717ef4
base64 strings may contain characters rejected by ident clients such
as "+". Use hex encoding and shorten the string a little.
git-svn-id: file:///srv/svn/repo/suika/trunk@395 f0ae65fe-ee39-954e-97ec-027ff2717ef4
For Network and Channel, the database only needed to define one Store
operation to create/update a record. However since User is missing an ID
we couldn't have a single StoreUser function like other types. We had
CreateUser and UpdatePassword. As new User fields get added (e.g. the
upcoming Admin flag) this isn't sustainable.
We could have CreateUser and UpdateUser, but this wouldn't be consistent
with other types. Instead, introduce User.Created which indicates
whether the record is already stored in the DB. This can be used in a
new StoreUser function to decide whether we need to UPDATE or INSERT
without relying on SQL constraints and INSERT OR UPDATE.
The ListUsers and GetUser functions set User.Created to true.
git-svn-id: file:///srv/svn/repo/suika/trunk@324 f0ae65fe-ee39-954e-97ec-027ff2717ef4
The user.updateNetwork function is a bit involved because we need to
make sure that the upstream connection is closed before re-connecting
(would otherwise cause "Nick already used" errors) and that the
downstream connections' state is kept in sync.
References: https://todo.sr.ht/~emersion/soju/17
git-svn-id: file:///srv/svn/repo/suika/trunk@313 f0ae65fe-ee39-954e-97ec-027ff2717ef4
An exported function makes it look like it can be called from any
goroutine.
git-svn-id: file:///srv/svn/repo/suika/trunk@309 f0ae65fe-ee39-954e-97ec-027ff2717ef4
Previously, the downstream nick was never changed, even when the
downstream sent a NICK message or was in single-server mode with a
different nick.
This adds support for updating the downstream nick in the following
cases:
- when a downstream sends NICK
- additionally, in single-server mode:
- when a downstream connects and its single network is connected
- when an upstream connects
- when an upstream sends NICK
git-svn-id: file:///srv/svn/repo/suika/trunk@296 f0ae65fe-ee39-954e-97ec-027ff2717ef4
