Each hash must be a cryptographic hash. Non-cryptographic hashes must be ignored. Broken hash algorithms should be avoided. MD5 is explicitly disallowed and must not be used.
The counter must be able to store numbers in the `0..2^62-1` range.
These hashes specify the current "heads" of the clog. This is similar to git heads, if you're familiar with them.
Viewing a channel's hash list should be restricted to anyone capable of joining the channel. This means banned users shouldn't have access to this command.
Manipulating a channel's hash list should be restricted to channel operators only.
The hash encompasses the message tags specified by the capability (e.g. `time` and `clog`), sorted according to UTF-8 byte order, and the contents of the IRC message, as seen in the following format:
Clogs are meant for channels that want public logging. An example is the Rust IRC channel. As such, anything in a clog should be assumed public.
It's possible to recover deleted clogs by setting up a separate IRC network and sending the right hashes on the right channel. However, you'd still need to know the hashes.
Thus, this isn't a vulnerability, because if you had the hashes, you could just request the logs directly, without going through the process of setting up an IRC network.
The network could be made to sign all hashes, but you'd need to share the signing key across all servers for it to work correctly. This still doesn't prevent someone
from getting access to an intercepted, correctly-signed hash, and by sharing the signing key you increase the attack surface.
The server can and should be able to "undo" hashes. This is useful if, for example, someone posts child pornography - you likely don't want that permanently recorded in a channel's history.
[FIXME there may be more]
The `SYNC` CTCP (informative)
-----------------------------
*This section is informative.*
The `SYNC` CTCP is a hypothetical CTCP for syncing logs.