MessageTag Manager: Allows server owners to permit specific client-to-client tags

[ValwareIRC]

No description provided.

[syzop]

We talked about this in the development team and as you know our current stance is documented under https://www.unrealircd.org/docs/FAQ#How_can_I_allow_other_message_tags.3F

In UnrealIRCd you need to have a module for each message tag. See the Message tag article for all the built-in supported message tags. UnrealIRCd supports almost all IRCv3 server message tags.

For client message tags too, a message tag handler needs to be loaded by a module. This is a design decision. The IRCv3 work group created client message tags where 1) the server has no idea which client tags the client supports and 2) allows a lot of traffic via message tags (4096 bytes per line, much more than the convential 512 bytes per line). This was with good intentions, allowing tags to be created without having to wait for server support and lots of room (bytes), but according to the UnrealIRCd head coder this creates a number of security and moderation issues. These problems are explained in detail in this IRCv3 discussion thread. In UnrealIRCd we deal with these problems by requiring a module for each message tag, including client message tags, these modules can then inspect and filter specific values.

Examples of client tags that we support out of the box (as seen in the Message tags article) are +typing and +draft/reply. As discussed in the IRCv3 discussion thread quoted earlier, the potential problems are under control for these tags. The +typing tag allows only a few values and the the +draft/reply tag only allows limited data (a msgid). And just as important: both these tags pose zero to nearly no moderation problem or issues for clients that don't see these tags.

An example of a tag that we will not support in UnrealIRCd is +draft/react. The problem is that ONLY clients supporting that tag can see the text of the reaction, and all other people in the channel don't see the text. This causes confusion and moderation issues and destroys the general principle of IRC where everyone can run their own client of choice and be "part of the conversation".

All in all, UnrealIRCd takes the middle ground: it is not one of the IRCds that refuses to implement (client) message tags, but also not one that blindly allows 100% through with all its consequences.

If you have a (client) message tag in mind that is not supported out of the box:

• Check out https://modules.unrealircd.org/ to see if there's a 3rd party module for it. At the time of writing there are 3rd party modules for +draft/react and +draft/display-name.
• Consider raising an issue on https://bugs.unrealircd.org/ for the tag, explaining why the message tag would be beneficial to the general audience and a link to the formal specification. Taking into account what has been said in this FAQ item.
• If you don't think the tag is useful to the general audience but is very specific to your network, then consider making a 3rd party module. You can peek at the existing 3rd party modules or official message tag modules. Things to keep in mind while coding such a module are: contain the length of the message tag and, if possible, the content. Other thoughts: think about what would happen if a client does not support the message tag and thus would not display it or take any action, would it cause confusion or issues? What if someone would flood witht his tag? You can also, optionally, create any other restrictions on the tag if you like, for example, requiring a services account, a certain mode, oper status, or whatever you like.

What your module does is allow the admin to configure tags and then allow these blindly through without really much or actually any checking, it checks just the name, not the value.

In message tag modules the idea is that you do some value validation, length/syntax but also an example would be if you allow a tag that does reactions, you could apply channel mode +G filtering in the reaction, so you can't evade +G by using react rather than normal messages. And with for example display-name you could have similar thoughts.

This module can't do that, it's generic.

So we could still allow this module, but it should then be noted that specific modules are very much preferred. The +G filtering for react is an example, but more generally modules tend to limit length and syntax. Almost no message tag needs the full 4KB, which is quite ridiculous in my opinion.

In our dev team some say we should not allow this module, because this complicates things to users too much, they would likely and quite easily think that just loading this module and then listing the tags they want to use, like +draft/react and the like, and they are done, why would they install any other module to do with tags? This one would do great, and it fixes them all !!! But... then you loose all the benefits of filtering and sanity checking of those other modules. I think that is a fair point.

But I don't know... i am a bit stuck on this. There are pro's and con's but I have trouble deciding. The only thing I know is that I would not allow this in unrealircd itself, but that is not on the table anyway, this is about a third party module, and in third party modules we tend to allow almost everything. But even then, lots of the logic and comments still apply and it's so easy to make users make bad decisions with this module.

[ValwareIRC]

Please note my word of caution about validation in the README (any reader)

[syzop]

In https://bugs.unrealircd.org/view.php?id=6411 westid suggested adding more value checks. Like max key length, allowed values wildcard/regex, limiting by security group. I have also suggested part of these in the past (though not limiting by the security group, that idea is novel).

I'm not sure if that will convince me or the other devs, but it is at least a good thought if you are going this way. What do you think about it?