From [1]:
> Distinct from a normal message, a numeric reply MUST contain a
> <source> and use a three-digit numeric as the command.
[1]: https://modern.ircdocs.horse/#numeric-replies
This fixes for example, being unable to use /back after going /away in hexchat. Hexchat is unable to parse the 305/306 numerics without the prefix, so assumes you aren't away, and doesn't let you run /back
This passes the STATUSMSG isupport through, and it ignores statusmsg prefix when routing messages through the PRIVMSG, NOTICE, and TAGMSG handler so they will show up in the correct history. Because it doesn't modify the message the statusmsg sigils show up correctly for the user on receipt.
Without this PR the statusmsg messages still come through to the client, but they get misrouted by clients expecting STATUSMSG to be specified in 005 and they don't go into the right channel history.
Closes: https://todo.sr.ht/~emersion/soju/124
Set it in downstreamConn.welcome instead. Makes it clearer that it
must not be accessed before welcome is called (because it can only
be accessed from the user goroutine).
We were unconditionally using the ASCII case-mapping in updateNick(),
for instance.
Introduce downstreamConn.casemap to fix this, and use it everywhere.
No need to re-check that a Web Push subscription is valid every
time a downstream connects. Mobile devices may reconnect pretty
frequently.
Check at most once a day.
This adds a new config option, `logs db`, which enables storing chat
logs in the soju database.
Regular store options, CHATHISTORY options, and SEARCH operations are
supported, like the fs logs backend.
Messages are stored in a new table, Message. In order to track the list
of targets we have messages for in an optimized manner, another database
is used: MessageTarget.
All new requests are backend by indexes so should be fast even with
hundreds of thousands of messages.
A contrib script is provided for migrating existing logs fs chat logs to
the database. It can be run with eg:
go run ./contrib/migrate-logs/ logs/ sqlite3:soju.db
Co-authored-by: Simon Ser <contact@emersion.fr>