public-mirrors/reflectionircd
1
0
Fork 0
mirror of https://git.sr.ht/~emerson/reflectionircd synced 2025-04-13 09:59:52 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

spec work

Browse source
This commit is contained in:
emerson 2022-02-01 17:46:22 -05:00
parent d5dd3f8f51
commit 038d04ad96
3 changed files with 52 additions and 77 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

60
docs/specs/delete-message.md
View file

@ -1,60 +0,0 @@
---
title: Message Editing and Deletion
layout: spec
work-in-progress: true
copyrights:
-
name: "Emerson Veenstra"
email: "ircv3@emersonveenstra.net"
period: "2022"
---
## Notes for implementing work-in-progress version
This is a work-in-progress specification.
Software implementing this work-in-progress specification MUST NOT use the
unprefixed `edit-message` capability name or `edit-message` and `delete-message` tags. Instead, implementations SHOULD
use `draft/edit-message` capability and `draft/edit-message` and `draft/delete-message` tags to be interoperable with other
software implementing a compatible work-in-progress version.
The final version of the specification will use an unprefixed capability name.
## Introduction
This specification describes a standardized way to change or delete messages that have been sent.
## Implementation
Servers and clients implementing this spec MUST also implement the `message-tags` capability.
### Message editing
To edit a message, clients send the edited message with a tag of `edit-message`. This tag has a required
value of the `msgid` from the original message. The edited message MUST have the same command and first
parameter as the original message, unless it is being changed into a multiline message (see below)
Servers MUST support editing `PRIVMSG`, `NOTICE`, `TAGMSG`, and `PART` messages, and MAY support editing
any other type of message. Servers SHOULD enforce all checks that they normally would for that specific
type of message (line length, color stripping, censoring, etc.) and return appropriate numerics if the
message fails a check.
If the server has any persistent history store for the type of message that is edited,
To edit a message, clients send an `EDITMSG` tag to the channel or user that the original message was sent to.
This message MUST have a `draft/target-msgid` tag with a required value of the `msgid` to edit.
To request message deletion, clients send a `DELETEMSG` to the channel or user of the original message.
This `DELETEMSG` MUST have the tag `draft/target-msgid` with a required value of the `msgid` of the
message to delete. It MAY have an optional second parameter to specify a reason for deletion.
Clients who receive a `DELETEMSG` with the `draft/target-msgid` tag MUST remove all displayed content from
the specified `msgid`. If the original message is ephemeral, clients SHOULD remove it entirely;
otherwise they MUST replace the content with the deletion reason or a generic substitute.
Servers MUST ensure that the user requesting deletion has sufficient privileges to delete the specified
message. Servers MUST remove the content of the original message from all persistent history stores, and
MAY replace the content with a generic deletion message if needed.
## Examples

47
docs/specs/edit-message.md Normal file
View file

@ -0,0 +1,47 @@
---
title: Message Editing and Deletion
layout: spec
work-in-progress: true
copyrights:
-
name: "Emerson Veenstra"
email: "ircv3@emersonveenstra.net"
period: "2022"
---
## Notes for implementing work-in-progress version
This is a work-in-progress specification.
Software implementing this work-in-progress specification MUST NOT use the unprefixed `edit-message` capability name or `edit-message` and `delete-message` tags. Instead, implementations SHOULD use `draft/edit-message` capability and `draft/edit-message` and `draft/delete-message` tags to be interoperable with other software implementing a compatible work-in-progress version.
The final version of the specification will use an unprefixed capability name.
## Introduction
This specification describes a standardized way to change or delete messages that have been sent to clients.
## Implementation
Servers and clients implementing this spec MUST also implement the `message-tags` capability.
### Message editing
To edit a message, clients send the edited message with a tag of `edit-message`. This tag has a required value of the `msgid` from the original message. The edited message MUST have the same command and first parameter as the original message, unless it is being changed into a multiline message (see below)
Servers MUST support editing `PRIVMSG`, `NOTICE`, `TAGMSG`, and `PART` messages, and MAY support editing any other type of message. Servers SHOULD enforce all checks that they normally would for that specific type of message (line length, color stripping, censoring, etc.) and return appropriate numerics if the message fails a check.
Client tags attached to the original message MUST be attached to the edited message to preserve or edit their value. If a client tag in the original message is not included in the edited message,
If the server has any persistent history store for the type of message that is edited,
### Message deletion
To delete a message, clients send a `DELETEMSG` message to the channel or user that the original message was sent to. The message MUST have a `draft/delete-message` tag with the msgid to delete. The message MAY have a second parameter, which is the reason for deletion.
Clients who receive a `DELETEMSG` with the `draft/delete-message` tag MUST remove all displayed content from the specified `msgid`. If the original message is ephemeral, clients SHOULD remove it entirely; otherwise they MUST replace the content with the deletion reason or a generic substitute.
Servers MUST ensure that the user requesting deletion has sufficient privileges to delete the specified message. Servers MUST remove the content of the original message from all persistent history stores, and MAY replace the content with a generic deletion message if needed.
## Examples

22
docs/specs/extended-invite.md
View file

@ -13,35 +13,23 @@ copyrights:
This is a work-in-progress specification.
Software implementing this work-in-progress specification MUST NOT use the
unprefixed `extended-invite` capability name. Instead, implementations SHOULD
use the `draft/extended-invite` capability name to be interoperable with other
software implementing a compatible work-in-progress version.
Software implementing this work-in-progress specification MUST NOT use the unprefixed `extended-invite` capability name. Instead, implementations SHOULD use the `draft/extended-invite` capability name to be interoperable with other software implementing a compatible work-in-progress version.
The final version of the specification will use an unprefixed capability name.
## Introduction
This specification extends the `INVITE` command to allow for an optional reason.
The reason can be used to give more context around why the invite was sent.
This specification extends the `INVITE` command to allow for an optional reason. The reason can be used to give more context around why the invite was sent.
## Implementation
Servers implementing this spec MUST also implement the `invite-notify` capability. Clients SHOULD
negotiate the `invite-notify` capability when negotiating `extended-invite`.
Servers implementing this spec MUST also implement the `invite-notify` capability. Clients SHOULD negotiate the `invite-notify` capability when negotiating `extended-invite`.
## Capabilities
Clients that have negotiated the `extended-invite` capability MAY add a final parameter on
an `/INVITE` command. This parameter is to give the target user context for the invite. This
parameter MUST NOT cause the message to exceed the maximum allowable line length of the
server.
Clients that have negotiated the `extended-invite` capability MAY add a final parameter on an `/INVITE` command. This parameter is to give the target user context for the invite. This parameter MUST NOT cause the message to exceed the maximum allowable line length of the server.
Servers that implement `extended-invite` MUST accept `INVITE` commands with three parameters.
If the user receiving the invite has negotiated `extended-invite`, the server sends the
final parameter to that user. Additionally, the final parameter is added to the `INVITE` command
sent to any users that have negotiated both the `extended-invite` and `invite-notify` capabilities.
Servers that implement `extended-invite` MUST accept `INVITE` commands with three parameters. If the user receiving the invite has negotiated `extended-invite`, the server sends the final parameter to that user. Additionally, the final parameter is added to the `INVITE` command sent to any users that have negotiated both the `extended-invite` and `invite-notify` capabilities.
## Examples