See https://ircv3.net/specs/client-tags/reply for the draft.
Can be used by clients to indicate to which message they are writing
a reply. This can be especially useful for bots, to indicate that
a response belongs to a user request, eg a !trigger.
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.
This is the work from May 3rd.. need to commit it so i can merge the
flood protection that is related to this...
The final implementation will still need tweaking before pushed.
[skip ci]
so they can fetch more history than the standard on-join history.
In the future we are also likely to implement IRCv3 CHATHISTORY
once that becomes an official specification. However, until it is
specified and until most major clients support it, several years
are likely to pass. It would be a shame to withhold channel
history to many end-users in the meantime when it takes so little
effort from us to provide an easy command.
See also
https://www.unrealircd.org/docs/Channel_history
And in particular the new section:
https://www.unrealircd.org/docs/Channel_history#Playback_frontends
which explains the relationship between on-join playback,
HISTORY and CHATHISTORY.
to be a bit less ugly. The module is loaded by default so you can
still use set::options::identd-check like before, even though I
hate ident... it's old shit... still, other's seem to like it.
More changes will follow later. There is still some ident stuff
in the core at the moment and the module is currently PERM, which
largely (but not entirely) defeats the purpose of being a module.
That will be fixed at a later time as well.
REQMODS Gmodname:version ....
to:
SMOD G:modname:version ....
Also, call the module require-module to be consistent with the
naming of the configuration directive.
Not sure yet of the set name, but call it set::require-module for
now as well.
so you can use set::restrict-commands without having to loadmodule.
Restrict the LIST and INVITE commands in the example.conf, which is
often a good idea. Finally, document the configuration/usage at:
https://www.unrealircd.org/docs/Set_block#set::restrict-commands
So rename src/modules/m_*.c to src/modules/*.c and update makefiles
and modules.default.conf. Also remove m_ at various places in the
source files, but not the CMD_FUNC(), just the module name.
UnrealIRCd already protects (for maaaany years) with ping cookies against
this attack. Making the m_nopost redundant.
Also, another module may be more useful (more on this soon...).
explicitly do not want to remember any channel history, such as on
a hub server to save memory.
Also, on Windows, ensure to compile all history_backend_*.c
For example, msgid / message-ids is not a CAP, while server-time is.
There mere fact of something being in CAP or not shouldn't cause
something to be in different directories ;).
Previously various information was only available for directly attached
servers, since it is communicated via PROTOCTL.
Now, we will also communicate information about leafs behind us.
IRCOps can use the /SINFO command to see these server features.
Services codes don't need to do anything, or at least are not expected
to do anything. They can still receive the information and do something
with it, of course...
Read the following technical documentation for full information,
as it will outline very specific rules for using the command S2S:
https://www.unrealircd.org/docs/Server_protocol:SINFO_command
https://www.unrealircd.org/docs/Authentication
And "require sasl" is now "require authentication"
(the old name will only raise a warning, not cause an error)
Note that authprompt currently only does the "require authentication"
stuff and not yet the soft-xx actions. That will be something for
later this week, but I've already documented it as such (here and
there anyway).
We previously introduced the "require sasl" block which allows you to
force users from certain IP addresses to authenticate with their nickname
and password via SASL. We now offer a new experimental module called
'saslemulation' which will help non-SASL users by showing a notice and
asking them to authenticate to their account via /AUTH <user>:<pass>.
See https://www.unrealircd.org/docs/Set_block#set::sasl-emulation
Note that this is work in progress, although the functionality of
already works. Still need to do some cleaning and expand the scope.
And more testing...
Bram Matthys