Add the CHATHISTORY extension specification. #292

ghost · 2017-01-02T22:47:36Z

jwheare · 2017-01-02T23:06:07Z

Interesting spec. Can you elaborate why msgid is required?

prawnsalad · 2017-01-03T00:51:28Z

As mentioned on IRC I've been getting this idea into the next version of Kiwi IRC. Something that stands out during implementation:

No acknowledgement by the server of the command is required other then returning the requested content.

It would be tidier if this was required to send an empty batch if there is no content to be returned. Just so the client doesn't sit there waiting for nothing.

ghost · 2017-01-03T01:02:47Z

@jwheare The draft/msgid is to allow for usage of the draft/reply tag in servers where multiple users may have the same scrollback content and a user wishes to reply to an older message. The draft/msgid would be that which the server originally sent to clients. If a user replies to a scrollback message, other users with the same history can scrollback as well and see the original message replied to.

@prawnsalad Agreed & updated.

dequis · 2017-01-03T01:08:43Z

Thanks for taking the time to write a spec for this!

This should probably be together with the other extensions, not just a batch type. In fact, I don't see a strong reason for this to use a new batch type, if it's just chathistory plus event replay.

Please read the previous discussion on why event replay wasn't added as part of the chathistory batch: #156 - the short version is that the way this spec handles it isn't enough.

to allow for usage of the draft/reply tag

While I agree that sounds desirable and that all messages from history should have an ID (also helps with deduplication), there's no need to make that into a requirement.

ghost · 2017-01-03T01:33:24Z

@dequis Do you suggest the extension be implemented as an RPL_ISUPPORT 005 command or as the scrollback capability? The original implementation I had was as a CAP but initial feedback suggested to simply send the 005 numeric instead.

While I agree that sounds desirable and that all messages from history should have an ID (also helps with deduplication), there's no need to make that into a requirement.

Agreed. Updated to make draft/msgid optional but recommended.

dequis · 2017-01-03T01:36:49Z

Yeah just an ISUPPORT token is fine for this.

prawnsalad · 2017-01-03T06:02:58Z

The changes to use chathistory makes it more confusing now. Sending the SCROLLBACK command to get a chathistory batch type now uses 2 different terms to refer to the same thing - scrollback.

Would there be anything stopping us from using a CHATHISTORY command instead to keep things consistent?

SadieCat · 2017-01-03T06:04:01Z

extensions/scrollback-3.3.md

+    @batch=ID;draft/msgid=UUID;time=YYYY-MM-DDThh:mm:ss.sssZ :nick!ident@host PRIVMSG target :message
+    @batch=XNyDSitp9MvcX;draft/msgid=eb703092-0782-4c28-bf7c-f9e5c45963ca;time=2016-11-19T18:02:01.001Z :[email protected] PRIVMSG #channel :The SCROLLBACK specification is going to be fantastic!
+### NOTICE
+    @batch=ID;draft/msgid=UUID;time=YYYY-MM-DDThh:mm:ss.sssZ :nick!ident@host NTOICE target :message


Fixed in d261046

SadieCat · 2017-01-03T06:05:12Z

extensions/scrollback-3.3.md

+#### Format
+The `scrollback` content can requested using timestamps:
+
+    SCROLLBACK target timestamp=YYYY-MM-DDThh:mm:ss.sssZ message_count


Wouldn't it be better to make it two parameters rather than using one separated with =?

Also:

Can message_count be negative to go backwards?

Should the max message_count be in the ISUPPORT token?

What numerics are sent if message_count is invalid?

Wouldn't it be better to make it two parameters rather than using one separated with =?

No preference either way. Any reason two parameters are better?

Can message_count be negative to go backwards?

Backwards in what sense? Send messages in reverse order or else? What is the use case?

Should the max message_count be in the ISUPPORT token?

Added in c4883c0

What numerics are sent if message_count is invalid?

Oversight and not considered. Suggestions?

SadieCat · 2017-01-03T06:06:57Z

extensions/scrollback-3.3.md

+## Current Implementations
+A ZNC-module implementation exists as [znc-scrollback](https://github.com/MuffinMedic/znc-scrollback). Client-side support for the ZNC module is in progress. Interest in supporting the batch type and command without ZNC has also been obtained, although specifics are not available at this time.
+
+[batch]: batch-3.2.md


This should link to the website pages for those specs rather than the markdown documents.

Fixed in d261046

ghost · 2017-01-03T06:23:44Z

@prawnsalad Fixed in d261046 - Use chathistory as both extension and batch type for consistency.

SadieCat · 2017-01-03T06:32:34Z

I'm wondering if for the purpose of this specification we might be better off introducing a new 'HISTORY' batch type which works similar to chathistory but for all messages instead of just PRIVMSG/NOTICE. The chathistory batch was only really intended for lightweight stuff like ZNC scrollback and InspIRCd's chathistory module.

dequis · 2017-01-03T06:44:51Z

a new 'HISTORY' batch type which works similar to chathistory but for all messages instead of just PRIVMSG/NOTICE

A new batch type will have the same problems the chathistory batch had. Batch types by themselves can't introduce the sort of behavior changes we need to stop (for example) a QUIT from the past making someone quit in the present.

We haven't talked much about how to do the event replay thing, maybe it's worth doing it in a new issue. But the ideas i have in mind could reasonably be added retroactively to chathistory.

Zarthus · 2017-01-04T00:01:25Z

I have some serious concerns about how this is going to be properly handled security wise.

I think for bouncers this'll be great, but for an ircd I can think of many ways in which this can be abused, and i'm not sure to which point it would be a violation of privacy and where the line'll be drawn. Logs would be very unlikely to have the state of a channel knowledge.

Some of the below points don't necessarily need to be mentioned in the spec, but I'm curious on how some things would be handled nevertheless.

I would consider getting some numerics for errors (to which point it is relevant to IRCv3): What should happen if I do a /CHATHISTORY #channel-i'm-not-in or /CHATHISTORY #secret-channel? Personally, I think access should be rejected, but the specification gives no guidance on how to do this.

User1 sends STATUSMSG(@) to #coolchannel
User1 ops User2 in #coolchannel
User2 does a /CHATHISTORY #coolchannel

Should they receive the opnotice they were not opped for?
I think it'll be hard to keep track of every single edge case.

User1 accidentally pastes their password, email, or address. While they change it, do we want to permit a way to delete chathistory? Should the user be able to do it for their own messages?
- This doesn't have to be the user themselves, plenty of doxxing attempts happen on IRC.

Some channels have confidentiality settings (think +mz, or +qz on charybdis)
opped User1 talks with deopped User{2,3,4}
Spam stops. -mz gets set.
Should User2 be able to request chathistory for the logs of when +mz was enabled?

coolserver.coolnework.net splits from hub.coolnetwork.net
User{1,2,3} chat on coolserver.* whilst split, User{4,5,6} chat on hub.*
coolserver.* rejoins hub.*
User1 wants to view the chat on hub.*'s chat, do they have to reconnect to hub to see it?

With that, an optional server parameter might be worth considering. Although with different specifications (like server-time) some sort of resync between messages for split servers could also exist in the future.

Services are down. My channel is SET RESTRICTED.
User2 joins my channel, and requests a CHATHISTORY.

With the above points, I really think that for a bouncer oriented specification, it'll be great. And while I'd like to keep the option for ircds to implement it, I have a hard time seeing how they would cover some of the problems. I imagine some sort of opt-in mechanic could work, but this comment is already getting quite long and it's a bit too much outside of the IRCv3 realm of influence.

…cations

kylef · 2017-01-14T06:02:03Z

extensions/chathistory-3.3.md

+### `CHATHISTORY` Command
+Chathistory content can be requested by the client to the server by sending the `CHATHISTORY` command to the server. A `batch` must be returned by the server. If no content exists to return, an empty batch should be returned to avoid the client waiting for a reply. Command support is sent to the client as the RPL_ISUPPORT 005 numeric `:irc.host 005 nick CHATHISTORY=max_message_count :are supported by this server`
+
+Both the `message_count` and `max_message_count` must be integers greater than 0. The client should not request a `message_count` greater than the `max_message_count` parameter sent in the command. If the `message_count` exceeds the `max_message_count`, server should return a number of lines equal to the `max_message_count` and the appropriate warning as described below.


What if the server/bouncer doesn't have any limitations on the buffer size. Could 0 perhaps indicate there is no max limit?

Agreed - Will update accordingly to set 0 = no limit.

kylef · 2017-04-21T13:03:38Z

extensions/chathistory.md

+### `CHATHISTORY` Command
+Chathistory content can be requested by the client to the server by sending the `CHATHISTORY` command to the server. A `batch` must be returned by the server. If no content exists to return, an empty batch should be returned to avoid the client waiting for a reply. Command support is sent to the client as the RPL_ISUPPORT 005 numeric `:irc.host 005 nick CHATHISTORY=max_message_count :are supported by this server`
+
+Both the `message_count` and `max_message_count` MUST be non-zero integers and `max_message_count` MUST be positive. The client should not request a `message_count` with an absolute value greater than the `max_message_count` parameter sent in the command. If the `message_count` absolute value exceeds the `max_message_count`, server should return a number of lines equal to the `max_message_count` and the appropriate warning as described below.


SHOULD should be in caps like MUST (RFC2119)

kylef · 2017-04-21T13:04:20Z

extensions/chathistory.md

+The `server-time` should be the time at which the message was received from the IRC server and the `batch id` a unique ID for the entire batch. `draft/label` SHOULD be included and MUST be a unique ID used to identify the `chathistory` request and any replies. A `draft/msgid` to identify each individual message MUST be the `draft/msgid` included when each message was first received from the IRC server.
+
+### `CHATHISTORY` Command
+Chathistory content can be requested by the client to the server by sending the `CHATHISTORY` command to the server. A `batch` must be returned by the server. If no content exists to return, an empty batch should be returned to avoid the client waiting for a reply. Command support is sent to the client as the RPL_ISUPPORT 005 numeric `:irc.host 005 nick CHATHISTORY=max_message_count :are supported by this server`


Is max_message_count required? Does omitting a value and having CHATHISTORY in ISUPPORT mean there are no limits enforced?

Yes, it's required. As per #292 (comment), it will be updating such that 0 can be used to indicate no limit exists.

kylef · 2017-04-21T13:07:55Z

extensions/chathistory.md

+If `message_count` is positive, content MUST be retrieved from after and not including the specified timestamp or `draft/msgid`. If the `message_count` is negative, content MUST be retrieved from before the specified timestamp or `draft/msgid`.
+
+#### Errors and Warnings
+If the server receives an improperly formatted `CHATHISTORY` command, the `CMD_INVALID` error code should be returned.


What is CMD_INVALID I don't see mention of it here or in RFC1459/RFC2812.

Wouldn't ERR_NEEDMOREPARAMS be sent if the required parameters are missing and not "CMD_INVALID"? Or ERR_NOSUCHNICK/ERR_NOSUCHCHANNEL if the target is non-existent?

If target can be multiple targets, is it possible to receive the ERR_TOOMANYTARGETS numeric?

kylef · 2017-04-21T13:15:02Z

extensions/chathistory.md

+
+Alternatively, content can be requested using a `draft/msgid`:
+
+    @draft/label=ID CHATHISTORY target draft/msgid=ID message_count


Can we make this format match that in other IRC specifications for consistency.

@draft/label=ID CHATHISTORY <target> draft/msgid=<message_id> <message_count>

Also not seeing much clarification on what target can be. Is it a direct target like #channel. Does it support comma separated values? #channel,#other-channel? Can we use * as wildcard?

I will specify the target as a single channel or query. The use of wildcards or multiple channels becomes problematic with draft/msgid, as each ID is unique only to a single message and the server would not know what to retrieve for each individual target.

What would the standard format be for the timestamp=YYYY-MM-DDThh:mm:ss.sssZ option? The use of server-time for either seems inappropriate.

I will specify the target as a single channel or query.

Okay if there is no wildcard, I am not sure how a client would know about the unread queries they have opened for individual nicks. Is there anyway a client would be able to load the available chat history targets?

znc-playback currently allows the wildcard so that clients can ask for all queries during launch so that they can load the nick queries.

CHATHISTORY is not intended to be a replacement for a playback buffer. Unless the spec is reworked, it currently has no concept of "read messages".

kylef · 2017-04-21T13:25:27Z

extensions/chathistory.md

+[batch]: http://ircv3.net/specs/extensions/batch-3.2.html
+[batch/chathistory]: http://ircv3.net/specs/extensions/batch/chathistory-3.3.html
+[server-time]: http://ircv3.net/specs/extensions/server-time-3.2.html
+[draft/msgid]: https://github.com/ircv3/ircv3-specifications/pull/285


Link can be updated to http://ircv3.net/specs/extensions/message-ids.html

kylef · 2017-04-21T13:25:41Z

extensions/chathistory.md

+[batch/chathistory]: http://ircv3.net/specs/extensions/batch/chathistory-3.3.html
+[server-time]: http://ircv3.net/specs/extensions/server-time-3.2.html
+[draft/msgid]: https://github.com/ircv3/ircv3-specifications/pull/285
+[draft/labeled-response]: https://github.com/ircv3/ircv3-specifications/pull/162


http://ircv3.net/specs/extensions/labeled-response.html

kylef · 2017-04-21T13:27:49Z

extensions/chathistory.md

+Both the `message_count` and `max_message_count` MUST be non-zero integers and `max_message_count` MUST be positive. The client should not request a `message_count` with an absolute value greater than the `max_message_count` parameter sent in the command. If the `message_count` absolute value exceeds the `max_message_count`, server should return a number of lines equal to the `max_message_count` and the appropriate warning as described below.
+
+#### Format
+The `chathistory` content can requested using timestamps:


I think this might lead to some timing problems down the line, since the timestamp is not unique per message. A server may receive two messages at the very same time and only one of these make it to a connected client before it disconnects.

Then the client will reconnect and ask for messages since the last message it seen which would not include the missing message.

This is required to account for certain use cases in which draft/msgid tags are not available, such as in ZNC 1.6+ logs, in the format of YYYY-MM-DD.log [HH:mm:ss].

kylef · 2017-04-21T13:30:09Z

extensions/chathistory.md

+A method for securely identifying the requesting user must exist to ensure content is sent only to the appropriate users and clients. See below for more information.
+
+## Security Considerations
+Secure identification of users and clients must exist in order to ensure that users cannot obtain history that does not belong to them. Use of account names, internal account identifiers, or certificate fingerprints should be strongly considered when matching content to users. The server must verify the current user's identity matches that of the desired content. This information is not sent as part of the `CHATHISTORY` command and must be validated via other means, such as those stated above. Access must be checked first and return an `ACCESS_DENIED` error as appropriate. If no `ACCESS_DENIED` error exists, the server can check for returnable content.


Secure identification of users and clients must exist in order to ensure that users cannot obtain history that does not belong to them

I'm not sure this is that clear. Some history do not necessarily "belong" to an individual user. Could I not request the chat history for a public channel on a server?

If I'm requesting public information I do not think any identification of the user or client needs to exist, only that the client is registered with the server.

Secure identification of users and clients must exist in order to ensure that users cannot obtain history that was not previously available to them at the time the messages were originally sent.

Using the reworded version:

Could I not request the chat history for a public channel on a server?

While you can certainly request chathistory from a public channel, you should not be able to request history if you weren't in the channel at the time the messages were originally sent. Allowing users to obtain history for channels they never used or are no longer joined to would essentially allow people to "spy" on channels.

While you can certainly request chathistory from a public channel, you should not be able to request history if you weren't in the channel at the time the messages were originally sent.

What would the point of requesting history if I have already seen the history because I was in the channel?

I think this should be down to networks/implementors, as a network might decide that channels without +p (private) and +s (secret) have publicly available logs. Or some other reasons behind it.

you should not be able to request history if you weren't in the channel at the time the messages were originally sent.

What would the point of requesting history if I have already seen the history because I was in the channel?

This limitation exists to prevent retrieval of content you weren't in the channel for. If you were in there at the time the messages were originally sent, then that qualifies as content "previously available to [you]"

This limitation exists to prevent retrieval of content you weren't in the channel for.

Shouldn't this be a consideration on an IRC server and not rules enforced by the specification? An implementation of CHATHISTORY might want to provide public history for some channels. For example some private IRC server at a company where all employees could join later and view existing history.

Good point. Will update to:

Secure identification of users and clients MUST exist in order to ensure that users cannot obtain history they are not authorized to view.

kylef · 2017-04-21T13:44:49Z

extensions/chathistory.md

+#### Format
+The `chathistory` content can requested using timestamps:
+
+    @draft/label=ID CHATHISTORY target timestamp=YYYY-MM-DDThh:mm:ss.sssZ message_count


YYYY-MM-DDThh:mm:ss.sssZ implies a specific format and not any valid ISO8601 date. I think the spec should clearly specify what is supported (ISO 8601) instead of only mentioning this format. ISO8601 valid dates may be in other formats like 2017-04-21T12:45:50+00:00.

The format given consistent with the server-time extension.

kylef · 2017-04-21T16:30:16Z

I spotted #293 which states:

The chathistory batch is currently limited to PRIVMSG and NOTICE and has no way to some events because they may be processed by the client in a way that affects the present channel state.

I don't see this actually mentioned anywhere so I think it should be mentioned that only PRIVMSG and NOTICE messages can be apart of the chat history.

ghost · 2017-04-21T18:14:38Z

PRIVMSG and NOTICES aren't limitations with this specification - it derives from limitations with the batch type, which this extension requires be supported. This is a dependency limitation.

If #293 addresses these issues and batch/chathistory no longer has these limitations, then CHATHISTORY would automatically support the additional event types.

SadieCat · 2017-08-25T10:32:47Z

extensions/chathistory.md

+
+Alternatively, content can be requested using a `draft/msgid`:
+
+    @draft/label=ID draftCHATHISTORY <target> draft/msgid=<message_id> timestamp=<timestamp>


draftCHATHISTORY?

SadieCat · 2017-08-25T10:33:22Z

extensions/chathistory.md

+### Examples
+The examples below are written with `draft/msgid` and `draft/label` tags included. These tags are recommended.
+
+#### Begin


Does each line need a title?

SadieCat · 2017-08-25T10:35:40Z

extensions/chathistory.md

+    @batch=ID;draft/msgid=ID;time=YYYY-MM-DDThh:mm:ss.sssZ :nick!ident@host PRIVMSG target :ACTION message
+#### End
+    :irc.host BATCH -ID
+#### Error


You should use a separate example for errors/warnings imo.

Zarthus · 2017-08-25T14:42:03Z

extensions/chathistory.md

+    @draft/label=ID draftCHATHISTORY <target> timestamp=<timestamp> +draft/msgid=<message_id>   
+
+#### Errors and Warnings
+If the server receives a`CHATHISTORY` command with missing parameters, the `ERR_NEEDMOREPARAMS` error code SHOULD be returned.


a`CHATHISTORY

Zarthus · 2017-08-25T14:44:24Z

extensions/chathistory.md

+
+If the number of lines between the `start` and `end` parameters exceeds the `max_message_count`, warn code `MAX_MSG_COUNT_EXCEEDED` SHOULD be returned. The command SHOULD continue to be processed as described above.
+
+If the target has no `chathistory` content to return or the user does not have permission to view the requested content, `ERR_NOSUCHNICK` or `ERR_NOSUCHCHANNEL` SHOULD be returned accordingly.


Why are we mixing numerics and "return verbs" (L77) like WARN and ERROR. If one format is superior to the other we should strive to include it for all cases, not some of them, and some of them not.

Can you explain what you mean? I'm not clear on the distinction. Are you suggesting we stick with ERROR and WARN and provide plaintext reasons rather than the codes?

Zarthus · 2017-08-25T16:54:29Z

extensions/chathistory.md

+A method for securely identifying the requesting user MUST exist to ensure content is sent only to the appropriate users and clients. See below for more information.
+
+## Security Considerations
+Secure identification of users and clients MUST exist in order to ensure that users cannot obtain history they are not authorized to view. Use of account names, internal account identifiers, or certificate fingerprints SHOULD be strongly considered when matching content to users. The server MUST verify the current user's identity matches that of the desired content. This information is not sent as part of the `CHATHISTORY` command and MUST be validated via other means, such as those stated above. Access MUST be checked first and return an `NO_SUCH_NICK` or `NO_SUCH_CHANNEL` error as appropriate. If no authorization error exists, the server can check for returnable content. If no returntable content is found, the server MUST send an `NO_TEXT_TO_SEND` error. The server MUST NOT expose the existence of valid targets to unauthorized users.


(18:53:52) <Zarthus> before i make an ass out of myself (18:53:58) <Zarthus> return an `NO_SUCH_NICK` or `NO_SUCH_CHANNEL` error (18:54:04) <Zarthus> typo "an" -> "a" yes/no (18:54:14) <Sadie> y

MUST send an NO_TEXT_TO_SEND error

Zarthus · 2017-08-25T16:57:21Z

extensions/chathistory.md

+    :irc.host BATCH -ID
+
+    @draft/label=ID :nick!ident@host CHATHISTORY ERR ERR_CODE
+


Without explicitly mentioning ERR as a verb (and WARN) implementors may think that this is not a constant string and get confused. A reference to some sort of document explaining subcommands may be useful

Zarthus · 2017-08-25T16:57:59Z

extensions/chathistory.md

+
+Content can also be requested up to a specified timestamp or `draft/msgid` in place of the `message_count`. The start and end parameter types do not have to match:
+
+    @draft/label=ID CHATHISTORY <target> timestamp=<timestamp> +draft/msgid=<message_id>   


timestamp without an @ symbol?

timestamp in this case is a command parameter, not a client tag.

Zarthus · 2017-08-25T17:00:06Z

extensions/chathistory.md

+The `server-time` SHOULD be the time at which the message was received from the IRC server and the `batch id` a unique ID for the entire batch. `draft/label` SHOULD be included and MUST be a unique ID used to identify the `chathistory` request and any replies. A `draft/msgid` to identify each individual message MUST be the `draft/msgid` included when each message was first received from the IRC server.
+
+### `CHATHISTORY` Command
+`CHATHISTORY` content can be requested by the client to the server by sending the `CHATHISTORY` command to the server. A `batch` MUST be returned by the server. If no content exists to return, an empty batch SHOULD be returned to avoid the client waiting for a reply. Command support is sent to the client as the RPL_ISUPPORT 005 numeric `:irc.host 005 nick CHATHISTORY=max_message_count :are supported by this server`


Perhaps instead of "an empty batch ..." we could do "CHATHISTORY SUCCESS NOOP" / NO_DATA whatever can be returned

ghost · 2018-11-04T14:53:32Z

Moved to #349

MuffinMedic added 3 commits January 2, 2017 17:41

Add scrollback batch type

d572c78

Update copyright year

ff83973

Add RPL_ISUPPORT 005 to command specification

25c7e8d

MuffinMedic added 2 commits January 2, 2017 19:56

Add draft/msgid support to scrollback command

577d9c5

Require batch reply

e2d46f5

Make draft/msgid optional

3871fa5

Reimplement extension using chathistory batch type

ff2ef80

ghost changed the title ~~Add the SCROLLBACK batch type specification.~~ Add the SCROLLBACK extension specification. Jan 3, 2017

Update URLs

8ae7bf9

SadieCat reviewed Jan 3, 2017

View reviewed changes

Rename scrollback to chathistory for consistency

d261046

ghost changed the title ~~Add the SCROLLBACK extension specification.~~ Add the CHATHISTORY extension specification. Jan 3, 2017

dequis mentioned this pull request Jan 3, 2017

Event playback (JOIN/PART/QUIT/NICK/etc as part of chathistory) #293

Closed

Add max_message_count parameter to ISUPPORT

c4883c0

Add error replies and draft/label

382968a

ghost mentioned this pull request Jan 4, 2017

Guidelines for subcommands and/or numerics ircv3/ircv3-ideas#6

Open

Specify label as draft

ed14f4c

MuffinMedic added 4 commits March 8, 2017 10:26

Specificy draft/label and draft/msgid purposes

e5f366b

Specify draft/label and draft/msgid purposes

545f645

Merge branch 'master' of https://github.com/MuffinMedic/ircv3-specifi…

89b5299

…cations

Merge branch 'master' of https://github.com/ircv3/ircv3-specifications

23cb023

ghost mentioned this pull request Apr 13, 2017

Add resume extension #306

Closed

kylef reviewed Apr 21, 2017

View reviewed changes

olofsjod mentioned this pull request Aug 17, 2017

ZNC *playback support weechat/weechat#323

Closed

MuffinMedic added 3 commits August 23, 2017 10:56

Standardize errors

9cc586a

Remove draft/ from CHATHISTORY command

d054b8b

Remove WIP draft prefix requirement

a210bfc

SadieCat reviewed Aug 25, 2017

View reviewed changes

Zarthus suggested changes Aug 25, 2017

View reviewed changes

MuffinMedic added 2 commits August 25, 2017 12:31

Change error codes to less-resemble existing numerics

4042cec

e and z

8759f86

Zarthus reviewed Aug 25, 2017

View reviewed changes

n

02aba74

Zarthus reviewed Aug 25, 2017

View reviewed changes

jwheare mentioned this pull request Aug 29, 2017

[message-tags] Describe a JSON encoding format and bump version to 0.3 #318

Closed

jwheare added the Implementation needed label Aug 29, 2017

Merge branch 'master' of https://github.com/ircv3/ircv3-specifications

88a3e1b

ghost closed this Nov 4, 2018

ghost deleted the master branch November 4, 2018 14:21

ghost mentioned this pull request Nov 4, 2018

Add the CHATHISTORY extension specification #349

Closed

This pull request was closed.


		Alternatively, content can be requested using a `draft/msgid`:

		@draft/label=ID CHATHISTORY target draft/msgid=ID message_count


		Alternatively, content can be requested using a `draft/msgid`:

		@draft/label=ID draftCHATHISTORY <target> draft/msgid=<message_id> timestamp=<timestamp>


		If the number of lines between the `start` and `end` parameters exceeds the `max_message_count`, warn code `MAX_MSG_COUNT_EXCEEDED` SHOULD be returned. The command SHOULD continue to be processed as described above.

		If the target has no `chathistory` content to return or the user does not have permission to view the requested content, `ERR_NOSUCHNICK` or `ERR_NOSUCHCHANNEL` SHOULD be returned accordingly.

		:irc.host BATCH -ID

		@draft/label=ID :nick!ident@host CHATHISTORY ERR ERR_CODE


		Content can also be requested up to a specified timestamp or `draft/msgid` in place of the `message_count`. The start and end parameter types do not have to match:

		@draft/label=ID CHATHISTORY <target> timestamp=<timestamp> +draft/msgid=<message_id>

Add the CHATHISTORY extension specification. #292

Add the CHATHISTORY extension specification. #292

Conversation

ghost commented Jan 2, 2017 • edited by ghost Loading

jwheare commented Jan 2, 2017

prawnsalad commented Jan 3, 2017

ghost commented Jan 3, 2017

dequis commented Jan 3, 2017 • edited Loading

ghost commented Jan 3, 2017 • edited by ghost Loading

dequis commented Jan 3, 2017

prawnsalad commented Jan 3, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Jan 3, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost commented Jan 3, 2017

SadieCat commented Jan 3, 2017 • edited Loading

dequis commented Jan 3, 2017

Zarthus commented Jan 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Apr 21, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Apr 21, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Apr 21, 2017 • edited by ghost Loading

Choose a reason for hiding this comment

kylef commented Apr 21, 2017

ghost commented Apr 21, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost commented Nov 4, 2018

ghost commented Jan 2, 2017 •

edited by ghost

Loading

dequis commented Jan 3, 2017 •

edited

Loading

ghost commented Jan 3, 2017 •

edited by ghost

Loading

ghost Jan 3, 2017 •

edited by ghost

Loading

SadieCat commented Jan 3, 2017 •

edited

Loading

ghost Apr 21, 2017 •

edited by ghost

Loading

ghost Apr 21, 2017 •

edited by ghost

Loading

ghost Apr 21, 2017 •

edited by ghost

Loading