Open SoniEx2 opened 2 years ago
One option would be to use a TLV for NOTICEs and TAGMSGs and another TLV for client-only tags. This seems reasonable, and send some text like "Your OTR plugin does not support this message. Please update your OTR plugin." in the main stream when the NOTICE/TAGMSG TLV is used.
So these:
@+example-client-tag=example-value PRIVMSG foo :some text
@+example-client-tag=example-value NOTICE foo :some other text
@+example-client-tag=example-value TAGMSG foo
would become something like this when OTR-encrypted:
{"message": "some text", "TLVs": {"message-tags": "+example-client-tag=example-value"}}
{"message": "Your OTR plugin does not support this message. Please update your OTR plugin.", "TLVs": {"message-ext": "NOTICE some other text", "message-tags": "+example-client-tag=example-value"}}
{"message": "Your OTR plugin does not support this message. Please update your OTR plugin.", "TLVs": {"message-ext": "TAGMSG", "message-tags": "+example-client-tag=example-value"}}
Currently, OTR only consistently encapsulates
PRIVMSG
. It should be possible to additionally conveyNOTICE
andTAGMSG
over the encrypted channel.For example, some messages look like this with current OTR:
but should ideally look like this with OTRv4:
with the contents of the client-only tag, as well as the message type, encapsulated into the encrypted channel.
References:
NOTICE
at all, as well as no handling of/me
/me
, altho arguably badly: https://github.com/irssi/irssi/blob/master/src/otr/otr-module.c#L126NOTICE
either.