What is your idea where ZNC would get the old messages from? Do you want to disable buffer playback when a client connects to ZNC and instead the playback is made available via chathistory?

I think this would behave in a similar manner to znc-playback module (https://github.com/jpnurmi/znc-playback / https://wiki.znc.in/Playback).

Thus if the capability is enabled, then we should prevent auto playback and allow the client to fetch the buffers as desired using the CHATHISTORY commands. The underlying data source will stay the same (CBuffer), if the upstream server also supports chathistory then we can forward the command upstream. I think we can treat forwarding chathistory to upstream server we can treat this as next steps and not part of initial support. At the moment only one IRCD supports chathistory (oragono).

I'd like to move away from the znc.in/playback batch identifier and switch to the chathistory one as it is standardised. This change can be separated as it isn't specific to the draft/chathistory capability, however it would need to be done as a dependency.

I think the following is needed for initial support:

• Use chathistory batch type instead of znc.in/playback
• Implement CHATHISTORY commands to client
  • Will need support for standard replies, if any CMessage logic will need to change (I do not know if this is the case).
• Expose capability draft/chathistory which would disable automatic playback

There are some additional things we can support, but as I read the spec I don't think they are mandatory and can be added after:

• Support message-ids - support for msgid so that we can support chathistory commands with msgid parameter alongside time operations. This is optional as it requires upstream server to support message-ids which at this point is rate for the larger networks.
• Support draft/event-playback capability - once enabled QUIT/PART/INVITE/KICK events should be played back in the history. Currently the module buffextras provides this functionality, however if I understand it correctly it serialises text into CBuffer. I think we will need to change CBuffer to be able to store other types of messages such as JOIN,PART,TAGMSG etc.
  • Open question: Should this be part of ZNC core? I can see it may be undesired and potentially a breaking change as these events can fill limited buffers to hide actual messages.
• Support forwarding chathistory to servers which support it natively

Technically unrelated, but I'd love to see:

• Storing messages in external system, (sqlite per network?)
  • Allow restarting ZNC without loosing messages
    • This limitation at the moment makes it hard for ZNC "operators" (those serving ZNC to multiple users). You don't know what users may have messages that can be silently lost to never be found again when you need to restart ZNC for patching etc.
  • This can potentially make the log module less useful since the re-playable buffers can be used instead
  • Prior art, oragono supports persisting messages in msql.

Allow restarting ZNC without loosing messages

savebuff module somewhat addresses this

msgid is indeed a non trivial feature, but it can be implemented
without upstream support: for example, messages ID could be the row ID
in a SQL database that stores the logs.

@hhirtz I don't think that's possible, the specifications states msgid value must be from the originating server, for which ZNC is not. ZNC wouldn't be able to enforce other uniqueness constraints for the upstream IRC network. This can create a confusing situation for clients because they may see msgid and have message-tags capability and expect commands like TAGMSG to work with message replies and reactions which ZNC won't be able to forward to the upstream server.

Message IDs spec:

The tag value MUST be a unique ID chosen by the originating server. Uniqueness in this context means that any other message transmitted on the entire network at any time MUST NOT share the same value

chathistory capability spec:

The msgid tag that identifies each individual message in a response MUST be the msgid tag as originally sent by the IRC server.

Meanwhile, bouncers implementing the server side of this specification may not be able to provide message IDs (when they are mediating for a server that does not support the message-tags capability). Therefore, clients with full support for message-tags MAY wish to implement fallback logic that relies only on server-time.

@hhirtz with such SQL ids, it's possible that different messages will clash:

1. Server without message id support sends a message
2. ZNC assigns it id 6346, and stores it. Sends that id to client, etc
3. Years later, server gains support of message ids
4. Server sends a message with id 6346. What ZNC is supposed to do with this message now?