ircv3-ideas
ircv3-ideas copied to clipboard
Message Deletion
Message Deletion
I'm making this as an idea here because I'd like to implement something , even as a stopgap to a potential 'message edit' spec.
This draft outlines the specifications of a message tag designated for deletion of previously sent messages in channels and private messages.
Motivation
Add a message tag which marks a message as deleted to the client, so the client can then delete it from its history.
Add an ISUPPORT token designated for managing messages where the use case for this specification would be message deletion.
Good clients will delete it from the buffer AND the logs to ensure that users choices are recognised as important, for example if someone accidentally sent a picture of some document containing personally identifiable information and they wished to remove that, then the client should be considerate of such situations.
Naming
I don't personally think delete is specific enough and so I propose delete-message/draft/delete-message, but I'm not bikeshedding and alternative name suggestions are welcome. For the purpose of demonstration, I will be using draft/delete-message in this proposal.
Syntax
The tag value can be an implementation-defined number of comma-delimited tokens in the form of Message IDs, and so an ISUPPORT token MAY be a comma-delimited list describing the number of accepted tokens. The first token of the potential list MUST describe the number of messages that can be specified for deletion.
For example if it were set to 5 and the client wished to delete 10 messages then the client will know to send two lots of 5. The name of the ISUPPORT token should be vague enough that it can include future message-manipulation tokens.
Again no bikeshedding, so for demonstration I will refer to the ISUPPORT token as "MANAGEMSG"
ISUPPORT:
Outlines the token and possible values. MUST NOT be empty. If the server implementing support does not wish to impose a limit, the value should be an asterisk (*)
Example of initial proposed ISUPPORT token where the number of allowed MessageTag IDs in the draft/delete-message value is 5:
MANAGEMSG=5
In the event another value is added, in this example the first value represents no deletion limit, and the second value token is regarding editing messages (i'm not sure why you'd wanna edit more than one message but I can't think of anything better off the top of my head) where the number of allowed MessageTag IDs in this hypothetical message-editing tag is 1:
MANAGEMSG=*,1
MessageTag
Outlines the tag and possible values. MUST NOT be empty:
Example where there is only one (1) message being deleted:
@+draft/delete-message=oYh1/ARgWpIUmPQECvKBve-GyEpjCQdQu6hAH8zQAn54g TAGMSG #ExampleChan
Example where there are multiple (3) messages being deleted:
@+draft/delete-message=oYh1/ARgWpIUmPQECvKBve-GyEpjCQdQu6hAH8zQAn54g,oYh1/ARgWpIUmPQECvKBve-pm59R0XdSP9GadWVKjUopA,oYh1/ARgWpIUmPQECvKBve-n2Zn+CPNoy/oEttc75VcVA TAGMSG #ExampleChan
Considerations
- Backwards compatibility: Currently due to the nature of IRC there is no backwards compatibility, and it would be up to the client to understand and honour the request to delete.
- CHATHISTORY: This would work generally well with
CHATHISTORY LATEST(as they would be able to easily catch theTAGMSG) and any automated channel history served by servers (as they would be able to easily catch theTAGMSG), but there would be problems aroundBETWEEN,AROUND, andBEFORE. - Honouring the request: How clients would handle this when it comes to nick changes. Clients SHOULD ensure the message being deleted was actually made by the user who is trying to delete the message, how they do this is vague but perhaps @jwheare can give some input around implementation decisions.
https://github.com/ircv3/ircv3-specifications/pull/425 ?
@jesopo I think my idea is more extensible and I think messagetags is optimal for this ;D
This is nice and simple and would allow clients to implement a quick-and-dirty "edit and resend" option
https://dev.twitch.tv/docs/irc/commands/#clearmsg noting that twitch does message deletion with a CLEARMSG command, tho i agree an ircv3 one should be dependent on message-ids
This is currently being specified at ircv3/ircv3-specifications#524, and has been implemented in several servers and clients. However this version includes the deleted message ID as a parameter, as it is required. Also the command in that PR is REDACT