Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message Deletion #103

Open
ValwareIRC opened this issue May 24, 2023 · 5 comments
Open

Message Deletion #103

ValwareIRC opened this issue May 24, 2023 · 5 comments

Comments

@ValwareIRC
Copy link

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 the TAGMSG) and any automated channel history served by servers (as they would be able to easily catch the TAGMSG), but there would be problems around BETWEEN, AROUND, and BEFORE.
  • 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.
@jesopo
Copy link

jesopo commented May 24, 2023

ircv3/ircv3-specifications#425 ?

@ValwareIRC
Copy link
Author

@jesopo I think my idea is more extensible and I think messagetags is optimal for this ;D

@ValwareIRC
Copy link
Author

This is nice and simple and would allow clients to implement a quick-and-dirty "edit and resend" option

@nektro
Copy link

nektro commented Dec 9, 2023

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

@4e554c4c
Copy link

4e554c4c commented Dec 9, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants