View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006411 | unreal | ircd | public | 2024-05-13 21:27 | 2024-06-26 09:05 |
| Reporter | westid | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | unable to reproduce |
| Status | closed | Resolution | no change required | ||
| Product Version | 6.1.5 | ||||
| Summary | 0006411: client tag configuration block | ||||
| Description | Dear UnrealIRCd Team I've taken an interest in the IRCv3 message tags and note how the working group are collectively ambitious to make the otherwise wonderful feature of message tags "to be the new CTCP" - I know that it wouldn't be very popular an idea to give client only tags cart blanche and I completely understand where you're coming from with the fact that the wanton availability of client only tags would cause a lot of people who weren't trying to view their session through debug messages / needing to go ridiculously out of their way to keep up with what could easily be turned into secret conversations some channel owners could find it particularly impossible to moderate There's something else though, that comes from the other side of it. I appreciate that Unreal does allow in a particular way some +client tags so long as their key values remain limited to the few values such that they conform to what is sent via TAGMSG like typing notifications, for instance ... Please don't be mad at me if this has been suggested before - I really did try to find out whether this was worth suggesting / bringing up here, before I started typing - I have only came across some of your team's confirmation that there are no reasons for someone who uses unreal to expect the frivolous inclusion of client only tags happening any time soon. Although given this, anyone would be free to write their own third party modules and that's what anyone would have to do in order to feature such tags on their network What I am suggesting here is a compromise. There are elements of IRC that message tags (in particular, client prefixed message tags) could facilitate in much more secure a way / be able to coexist without secret / unmoderate-able exchanges right under sysop's nose firing away This compromise would be something that is defined in the *configuration file* - where, in such a perfectly familiar format, especially so with security groups / mask items / extended channel & server ban criteria ... a message-tag block Idea is pretty much bread and butter - message-tag tagname { } in the config file ... what is allowed to be used as a value [maybe an explicit list? regex?] who is eligible to interact [maybe even separate send / receive thresholds] for instance not until someone has the reputation to be included in known-users / any other security group I can imagine this could turn out to be something akin to DENY DCC, where the configuration file decides what's allowed / what values it can contain / who can send or see ... I think this a good compromise it would be, between any client sending whatever the hell they like / by default not allowing any client tags unless an admin puts it in the server configuration specifically ... and there are so many tools available such as mask items / extended ban-style functionality / security groups / reputation score / central API Not gonna lie, I've never been particularly prominent about creating things out of C, and the concept of using third party modules / roulette wheel whether some such module would survive after every single ./unrealircd upgrade and maintain its intended functionality Your reasons which I've found in numerous forum posts as I searched for related TAGMSG / IRCv3 capabilities, I happen to agree with why you wouldn't want such tags to be used frivolously - but as the IRCv3 says that it intends to use tags as something "that will replace CTCP" - this is why I would be interested to see Things like websocket, or the JSON-RPC ... these increasingly powerful in their capability. I would never be able to write a third party module to create / include / validate the type of values a network admin-enabled client only message tag capability But if someone compiled, installed, and run on a node the latest version of UnrealIRCd, and message tags could be configured by creating a block with some parameters to set the rules of how its usage should be, then the average guy-off-the-street IRC operator would have no come-uppance because it wouldn't - until they decided to add a message-tag block to their server configuration file with information about it in the documentation wiki - would be perfectly fine as an opt-in, and because of it being opt-in unable to give anyone an opportunity to do the things you wouldn't want to allow people to do simply because some admin didn't set their configuration properly I hope this compromise would help. Thanks UnrealIRCd I hope you can find it in your heart for me | ||||
| Steps To Reproduce | This is a feature request. Sorry if in wrong place / I didn't search enough to find it's possibly been asked for before | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Hi there. While I agree with you, please check the conversation here: https://github.com/unrealircd/unrealircd-contrib/pull/94 |
|
|
Dear Val Good to hear from you again, keeping well I hope. I wrote a _proper_ message comprising everything but I lost all of the text and couldn't retrieve it again so here is what I basically said. I am having a meltdown now because everything I wrote had a point to it that agrees with both you and Bram so please don't facepalm my moronic pointless existence frought with this particular brand of self-deprecating stupidity - you both have the full-on truth when it comes to client only message tags, but since I clicked "Add Note" the IQ of the whole continent went down a few points on average Basically my propositional logic to writing this issue to suggest a feature leaned heavily on the fact that - for most IRC clients - unless you use /CTCP <target> ACTION then the entire history of IRC going back to RFC1459 has determined in a de-facto sort of way that _validation, parsing, tokens, replies, &c._ has always been something left primarily to the client and now [even more especially so since BATCH hasn't had trouble seamlessly upgrading in quality every IRC session because of its augmentation giving any request / message / properties / list entries / replies basically limitless-in-length [protocol / any other] messages] unless someone uses /CTCP <target> ACTION - but the obvious nature of why no one wants to prefer CTCP messages over client message tags in my opinion is that they are _just_ too identical to any other messages Even more basically, CTCP might as well be !version !ping .. &c. in that its function is literally of no further significance than NOTICE and PRIVMSG - other than that what else is there? [from the conversation you linked] "data" had such added worth if one was able to give each other the role of client A and client B - sender and recipient linked by server C - why? because even if there were added bits of information, even an entire conversation; the same logic applies when someone is being a cunt with you by breaking off into another language Sure, there's elitist amusement two people may be gathering one anohter as they speak in a way that see to begin with or haven't got the time to figure it out even if you may - but the bottom line is, if someone is so much of a pussy that they have to insult you in an uninterpretable medium, then there is nothing more about their character that rises even close to niche - I dare say sadly even nuance - above the tedium. Someone else in any given channel [if this kind of unmoderated thing was going on] would proudly be the first to proclaim: "ur such a pussy u have to use hidden messages to talk shit to 1 anothe2" something along those lines When I perused the way that you set out the config-file code, I _did_ come up with some things any network admin would benefit from this. Please bear in mind Bram [if you end up reading this] I think you're right and your reasoning for not wanting to throw your IRCd into the fray because of liberal support for new things introduced by IRC v3 but I think it will come down to this compromise [on most IRCd, anyway] message-tag wanker { maxkeylen 35; only-by { security-group { webirc-tls; operator; limitation-example; } } /* this next embedded bit is supposed to be an example of a "list of" values acceptable to convey this tag in command */ boldlygo { val "start*"; // although you already seem to have an idea of a field where you can just approve / put anything you want ... val "*end"; // ... you have so much unrealIRCd functionality like conditional @IF / security group / mask item, you pretty much wval { type regex; // have all the validation you can integrate into the _possible_ values wv "^Smoke (crack|cigar[ette]|heroin) every (night|day)$"; } } } I used to work as an intruder alarm engineer ... and there were always special sorts-of functionality in the control kits that by and large were never used by the customer. But when it was, it was beautiful No one's going to change their mind because of anything said by me, but all the same I think this is something that not only could, rather _should_ replace CTCP P.S. Val, I've never bothered with third party modules, and can't seem to find a way to install the code in the one you had written. Would it be possible you let me know how I could implement it into one of the servers on my network for curiosity testing? Kind Regards Westid Incorrigo Syx |
|
|
Hi, Westid, thanks for all the comments. Yeah it is a difficult topic. We have decided not to do this in UnrealIRCd itself, we had another conversation in the dev team half a year back and concluded it should still be like that. So that's why I'm closing this bug report / feature request. Still, just now, I have referred to the suggestions you posted here from https://github.com/unrealircd/unrealircd-contrib/pull/94 which is the third party module that Valware talked about. I still have my doubts on accepting that Pull Request... but with more value checking it would at least be better I think. If you want to see how that process goes, you can follow that URL. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-05-13 21:27 | westid | New Issue | |
| 2024-05-13 21:57 | Valware | Note Added: 0023187 | |
| 2024-05-20 01:29 | westid | Note Added: 0023189 | |
| 2024-06-26 09:03 | syzop | Assigned To | => syzop |
| 2024-06-26 09:03 | syzop | Status | new => closed |
| 2024-06-26 09:03 | syzop | Resolution | open => no change required |
| 2024-06-26 09:03 | syzop | Note Added: 0023230 | |
| 2024-06-26 09:05 | syzop | Note Edited: 0023230 |
