possible if it rounds off nicely, eg +H 100:7d. Note that the
existing syntax is still accepted, eg +H 20:1440 and +H 20:1440m
are both converted to 20:1d.
With potentially higher time values this change makes the mode
parameter a lot more readable.
Support for translating timevalues is already in UnrealIRCd 5.0.2
and higher, so should be fine for nearly everyone.
from https://ircv3.net/specs/extensions/chathistory
Current status of the module in UnrealIRCd:
* A significant part of this is done and working
* Currently in modules.optional.conf to get test exposure,
not yet loaded by default.
* CHATHISTORY subcommands implemented: BEFORE, AFTER, LATEST, AROUND
* It does not implement the subcommand "BETWEEN" yet
* It does not announce or recognize the (draft) CAP's yet
* It does not announce the ISUPPORT token CHATHISTORY=xx yet
* Testcases need to be written to validate everything
* There will be bugs, now, and also while implementing the rest
in the days to come.
* Fix channel history issues with writing on terminate
* Change tkldb and reputation to only write the db
on terminate and not on every REHASH anymore
..all this thanks to the new loop.ircd_terminating, so modules can
see the difference between regular rehash and terminating.
configuration on how history is stored (in memory and/or on disk).
This is similar to other disclosing policies like
unrealircd.org/link-security and unrealircd.org/plaintext-policy.
The reason for this cap (and similarly the other caps) is that
the user can make an informed decision on whether it finds the
policy/safety/privacy of an acceptable level or not.
Fixes for turning persist on/off on the fly (REHASH)
Make release notes a bit more clear.
not always kicking in on *line either.
We now check for shuns/*lines in user_account_login(), so upon
SASL or NS IDENTIFY etc. This also means that the client could
now be killed in that function, so callers should take extra
care and take that into account. We check for IsDead() in our
calls now (if it's our client anyway).
Hopefully this doesn't break anything.........
I forgot to include message tags earlier, so this is a breaking change:
-int hooktype_local_nickchange(Client *client, char *newnick);
-int hooktype_remote_nickchange(Client *client, char *newnick);
+int hooktype_local_nickchange(Client *client, MessageTag *mtags, char *newnick);
+int hooktype_remote_nickchange(Client *client, MessageTag *mtags, char *newnick);
Be sure to update your hooks!
You can use something like: #if UNREAL_VERSION_TIME>=202115
The new display field is called 'R', use something like:
WHO * %cuhsnfmdaRr
At the moment only "displaying" is available and not "searching"
on reputation. If you need that, you're stuck with the /REPUTATION
command at the moment. Too much hassle to implement that.
About reputation: https://www.unrealircd.org/docs/Reputation_score
the spamfilter. Only after a rehash it showed the me::name as the
setter. From now on we just display -config- in the setter field,
like we do for all the other TKLs as well (ELINE, ban xyz, etc).
if running multiple ircds from the same directory you sometimes get
weird messages otherwise (not that we really support such a thing
but i use it while dev'ing).
Not reported by anyone, but yeah.. who knows there is someone out there
that does this :D.
Also make it work the same like channeldb by spreading the event.
notices to IRCOps and in ircd.log.
See the release notes for more details.
Module coders:
You can use HOOKTYPE_CONNECT_EXTINFO to add your own additional
information as well. See get_connect_extinfo() for inspiration.
Use nvplist_add() or nvplist_add_fmt() to easily add your info
to the list.
Module coders II:
Small note: this moves the sending of the far connect notice
to /under/ HOOKTYPE_REMOTE_CONNECT instead of /above/.
The handshake delay exists so results from DNSBL's can be checked before
the user is fully online. Whenever someone is exempt from DNSBL checking
it serves no purpose, so we mark it that the user has no handshake delay.
This will speed up connecting by up to 2 seconds (by default).
Also updated WebIRC example to suggest this now:
https://www.unrealircd.org/docs/WebIRC_block#UnrealIRCd-side
The exempted ban types are only ones that will affect other connections as well,
such as gline, and/but not policy decissions such as bypassing qlines or maxperip.
Currently the list is: gline, kline, gzline, zline, shun, blacklist,
connect-flood, unknown-data-flood.
Suggested by PeGaSuS and others in https://bugs.unrealircd.org/view.php?id=5806
Bram Matthys