Spec to add a 3rd parameter to INVITE to give a reason/context for the invite. Matrix, Discord, Mattermost all have some form of this.
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 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 is used to give more context around why the invite was sent.
Implementation
Clients that have negotiated the extended-invite capability MAY add a third 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 adds the third parameter to the INVITE command sent to the user. Additionally, the third parameter is added to the INVITE command sent to any users that have negotiated both the extended-invite and invite-notify capabilities.
Servers SHOULD apply the same checks (rate-limiting, censoring, etc) for the final parameter as they do for a PRIVMSG or NOTICE to avoid abuse.
Examples
For example:
C: INVITE emerson #project-test :We're testing out our project in here!
S: n!u@h INVITE emerson #project-test :We're testing out our project in here!
Spec to add a 3rd parameter to
INVITEto give a reason/context for the invite. Matrix, Discord, Mattermost all have some form of this.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
extended-invitecapability name. Instead, implementations SHOULD use thedraft/extended-invitecapability 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
INVITEcommand to allow for an optional reason. The reason is used to give more context around why the invite was sent.Implementation
Clients that have negotiated the
extended-invitecapability MAY add a third parameter on anINVITEcommand. 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-inviteMUST acceptINVITEcommands with three parameters. If the user receiving the invite has negotiatedextended-invite, the server adds the third parameter to theINVITEcommand sent to the user. Additionally, the third parameter is added to theINVITEcommand sent to any users that have negotiated both theextended-inviteandinvite-notifycapabilities.Servers SHOULD apply the same checks (rate-limiting, censoring, etc) for the final parameter as they do for a
PRIVMSGorNOTICEto avoid abuse.Examples
For example: