Skip to content

Instantly share code, notes, and snippets.

@SoniEx2
Last active March 10, 2018 16:54
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save SoniEx2/441dd24964c7fb3dc13d124db20914a0 to your computer and use it in GitHub Desktop.

Clog Capability

Copyright (C) 2018 Soni L. <fakedme plus irkv3 at gmail dot com>

Overview

The soniex2.github.io/clog capability introduces:

  • New S2C command: MERGE
  • New tag: clog-id

The capability also requires:

  • server-time
  • echo-message

The capability replaces/deprecates the older message-ids tag.

Tag format

The clog-id tag is a case-insensitive hex-encoded sha3sum of the previous message. set of hex-encoded cryptographically secure hashes of the previous message, including crlf.

The hash is derived by sorting any non-client-only tags (including the clog-id itself) in UTF-8-betical order, and applying a set of hash functions to the result. Note that the server doesn't have to store the last message (or any sort of logs) in order to generate new messages - storing the hashes for the lastest message is enough.

The clog-id syntax is:

clog-id=hash_name:hash_value

MERGE command

The MERGE S2C command requires a clog-id and server-time tag, and may contain any other applicable tags, and takes the channel and the value of a clog-id as argument.

This is for use with multiple servers, which may not always sync nicely, for example through netsplits. The diverging clog-ids can then be MERGEd. Clients should be made aware of this change.

Deviations from the standard

Some IRCv3 specifications say you MUST NOT send message tags the client didn't specifically ACK. We go against this, and say that you SHOULD send ALL tags. This is because clients should be kept in sync with the server's clog-ids.

Clients following this specification MUST ignore tags they didn't specifically ACK.

While it's not strictly required for the server to send ALL tags, it's strongly recommended, as doing so saves a lot of trouble for the client.

Security considerations

Given the requirement of server-time and the fact that messages include a nickname and a hostmask, it's rather difficult to make two messages on the same channel collide. Given that PRIVMSG and NOTICE and TOPIC include the channel name, it's effectively impossible to make two messages on two different channels collide.

Thus, this is rather suitable as a permanent replacement to message-ids.

Note that because this uses plain hash functions, it's strongly recommended to only use hash functions which are:

  1. Collision resistant.
  2. Preimage resistant.
  3. Second preimage resistant.
  4. Length extension resistant.

For these reasons, it's strongly recommended to use SHA3-384 (or another of the SHA3 functions) over MD5, SHA1, or SHA2.

Special considerations

The hash MUST be computable/verifiable by the client.

This document recommends that SHA3-384 SHOULD be supported by all clients and servers. Future documents may change this recommendation.

Merge algorithms are left unspecified. However, this specification supports a wide range of them, including, but not limited to:

  • Unsynchronized merge on new message. ("Eventual consistency". Completely asynchronous.)
  • Blockchain style synchronous merge. (Eager merge. May delay messages.)
  • Blockchain style asynchronous merge. (Eager merge. Doesn't delay messages, but introduces merge latency.)
  • Never merge. Yes, really. (Not recommended.)

Further work?

Digital signing could be used, but would make these non-permanent. Having permanent, cryptographically secure message identifiers has rather useful properties besides those discussed in this specification.

Future versions of this specification may add support for HMAC. This should be backwards-compatible, as clients should simply ignore unknown hash functions.

Examples

@time=2018-02-19T22:33:33.000Z :source1@material!example.com PRIVMSG #channel :hello!
@time=2018-02-19T22:33:38.000Z;clog-id=sha1:324273f916cc4b6e9a1628aab305cfce6f8389aa,sha3-384:f3917fb64ab55118ae7e3ecf91f4654816a9363dd580d19b84eb85aa06e3caf78242fe35a5d125e65feb0e6dd1104888 :source2@material!example.com PRIVMSG #channel :hi!
@time=2018-02-19T22:33:40.000Z;clog-id=sha1:e06bd856c28f858dfe23d1a85e3f6ddbcfb79908,sha3-384:843b9b0a19bb583ccb6bd2f7aac3fdf015e8f374ef587ebb4670a7bc81f227d288702199ae543440269b2c9417fff2a1 :concurrent1@material!example.com PRIVMSG #channel :hello!
@time=2018-02-19T22:33:40.001Z;clog-id=sha1:e06bd856c28f858dfe23d1a85e3f6ddbcfb79908,sha3-384:843b9b0a19bb583ccb6bd2f7aac3fdf015e8f374ef587ebb4670a7bc81f227d288702199ae543440269b2c9417fff2a1 :concurrent2@material!example.com PRIVMSG #channel :hello!
@time=2018-02-19T22:33:59.001Z;clog-id=sha1:f694ae25d4af0e98ce474be3aa0693c3d55ca4ff,sha3-384:5613ceaa2354a3868064d28a0ce8d44f9cfbe1bb68c3780e53d7164155c0e828838dcc4a9f8425e1477549565a5ff917 MERGE #channel sha1:b81bd7dbf522abe867ba54b9ac9b34dd1ba0038e,sha3-384:36724b1ae41b0e9d03661c2e55c5f309d747f345196aa8d35a26f8782c5fdf0b7c9c24979eaf0994e912620275c0df9e
@time=2018-02-19T22:33:59.001Z;clog-id=sha1:825d0bf214666cf6bace97a338d2bcb31e921659,sha3-384:73f7847e19e09237dce1edcd7d7e8bd9c3dcb76ea731434703ca926c72a726de5861376c905f325d743e0cd7f2773b38 :source3@material!example.com PRIVMSG #channel :hey!
  • First message is root.
  • Second message refers to root.
  • Third and fourth message refer to second message.
  • MERGE refers to third and fourth messages.
  • Last message refers to MERGE.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment