View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004160 | unreal | ircd | public | 2013-01-09 10:40 | 2014-06-05 17:04 |
| Reporter | syzop | Assigned To | tmcarthur | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 3.4-alpha1 | Fixed in Version | 3.4-alpha1 | ||
| Summary | 0004160: Channel mode +u/+mu | ||||
| Description | Simple question: what to do about +u and +mu? There were a number of issues related to this, which are now closed. See the 'related to' in this bug report. Please discuss in this bugid# instead! Major questions are: * Do we still want +u at all? * Do we want special behavior when both +m and +u are set? Recurring questions are: * How do we solve the case where someone acquires or loses privilegs (such as +oaq) and needs to get an updated userslist. how do other ircds deal with this? updates NAMES has come by, which I dislike as it means you suddenly send a numeric out of the blue. other suggestions are sending channel joins or parts, which also seems silly but it is much more RFC-friendly. * Others? Well, discuss! ;) This all for Unreal 3.4.x. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| related to | 0003344 | closed | syzop | +u auditorium mode |
| related to | 0001750 | closed | syzop | Erratic Auditorium Mode (+u) Behaviour |
| related to | 0002160 | closed | syzop | Channel +u Ops |
| related to | 0002216 | resolved | syzop | More documentation for channel mode +u |
| related to | 0003348 | closed | syzop | +mu suggestion |
| related to | 0003682 | closed | syzop | Channel mode +u with +m causes certain issues |
| related to | 0003985 | closed | syzop | Channel Mode Request +u & +U |
| related to | 0004067 | closed | syzop | Make mode +u shows Halfops and Voices |
| related to | 0001051 | closed | syzop | Make chmode +u more client/user-friendly |
|
|
I can see the use for +mu. It does have a few inconsistencies associated with it. I think olene's suggestion at http://bugs.unrealircd.org/view.php?id=1750#c5942 fixes those. |
|
|
This is a mode and mode combination that isn't used very often. I think it would be better off as an optionally loaded module, which shouldn't be too difficult to do (just put in all the proper hooks and overrides, might need to create additional hooks for MODE and KICK to keep them quiet). |
|
|
As for channel list updates, sending a NAMES out of the blue would work, but it would be cleaner to send proper JOIN/PART |
|
|
What Steath said. I think sending NAMES out of the blue wouldn't be such a shock when a user changes their chanmodes as much as it would if we flooded the client with JOIN/PART messages which could cause client/script side flood issues in larger channels. With sending NAMES we could also send a server notice to the user telling them why they were sent NAMES to update their nicklist. |
|
|
The JOIN/PART would only be a flood issue if opping/deopping was a flood itself, right? |
|
|
I think that +u itself should be removed... the main purpose of it in reality is that it allows bot herders to hide their bots. While I understand that they can readd the feature, I think the only real practical aspect is the moderation component, which behaves like charybdis +z (as seen on freenode). |
|
|
the flooding I mentioned would fill your screen if you were in a large channel and suddenly seen 200 users join. On the client/script side, said JOIN would activate any script or client setting in place to react to users joining a channel such as clone detectors or auto-greeters that just suddenly went off 200 times because you just got opped. Conversely, NAMES shouldn't trigger any script event. |
|
|
Good point. |
|
|
From a code POV +u is a mess in the code and it's easy to make mistakes. From a users standpoint, nobody understands it. And from a protocol POV the current implementation is incomplete. So how does charybdis +z behave? What's also has been suggested before is delayed join (join-on-first-message). But I'm not sure if that has much to do with +u, except for the 'hiding'-part. Anyway, we need to discuss what to do with +u for 3.4.x. ( And of course, +z will stay +z in UnrealIRCd, we are not going to change letters just because another IRCd happens to use another letter. But that's another thing. ) |
|
|
Ah okay, that delayed join thing is in 0002906. Talking about complexity, that will add quite a bit. Remembers me that we should have some kind of 'can user X see user Y' function with hook support, instead of hardcoded rules all over the place :p. And charybdis +z just makes blocked messages (due to +m / +b etc) go to chanops. That's exactly what +mu does right now, but presumably without the <IRC> strangeness. We could make +u behave like charybdis +z. And leave the 0002906 idea (delayed join) over to a new channel mode +d/+D. If anyone feels like implementing it. How about that? |
|
|
"What Steath said. I think sending NAMES out of the blue wouldn't be such a shock when a user changes their chanmodes as much as it would if we flooded the client with JOIN/PART messages which could cause client/script side flood issues in larger channels. With sending NAMES we could also send a server notice to the user telling them why they were sent NAMES to update their nicklist." IMO we should not be randomly sending out NAMES, it may not break some clients but I'm sure there are a few that would have an issue with it. Also sending a server notice to tell users why they were sent NAMES would do nothing to explain to the client why it was getting one. I wouldn't mind seeing +u changed to work like the charybdis +z or removed all together. Hiding joins like +u does, in my opinion, was a horrible idea. |
|
|
per 0002906, we've removed +u for now in favor of +D/+d, w/ +mD you get only +vohaq visible. We could add special behavior if we want to "remove" people that had +vohaq from the user list later, but I think that should ideally be in a second bug. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-01-09 10:40 | syzop | New Issue | |
| 2013-01-09 10:40 | syzop | Relationship added | related to 0003344 |
| 2013-01-09 10:40 | syzop | Relationship added | related to 0001750 |
| 2013-01-09 10:40 | syzop | Relationship added | related to 0002160 |
| 2013-01-09 10:41 | syzop | Relationship added | related to 0002216 |
| 2013-01-09 10:41 | syzop | Relationship added | related to 0003348 |
| 2013-01-09 10:41 | syzop | Relationship added | related to 0003682 |
| 2013-01-09 10:41 | syzop | Relationship added | related to 0003985 |
| 2013-01-09 10:41 | syzop | Relationship added | related to 0004067 |
| 2013-01-09 10:45 | syzop | Relationship added | related to 0001051 |
| 2013-01-09 21:48 | Shining Phoenix | Note Added: 0017344 | |
| 2013-01-10 00:42 | Stealth | Note Added: 0017346 | |
| 2013-01-10 00:43 | Stealth | Note Added: 0017347 | |
| 2013-01-13 20:44 | katsklaw | Note Added: 0017353 | |
| 2013-01-13 20:45 | katsklaw | Note Edited: 0017353 | |
| 2013-01-13 22:07 | Shining Phoenix | Note Added: 0017354 | |
| 2013-01-14 08:18 |
|
Note Added: 0017355 | |
| 2013-01-16 02:14 | katsklaw | Note Added: 0017381 | |
| 2013-01-16 04:04 | Shining Phoenix | Note Added: 0017382 | |
| 2013-05-26 11:16 | syzop | Note Added: 0017687 | |
| 2013-05-26 11:16 | syzop | Status | new => feedback |
| 2013-05-26 11:23 | syzop | Note Added: 0017688 | |
| 2013-05-26 11:25 | syzop | Note Edited: 0017688 | |
| 2013-05-26 11:26 | syzop | Note Edited: 0017688 | |
| 2014-06-02 22:42 | ShawnSmith | Note Added: 0018167 | |
| 2014-06-05 17:03 | tmcarthur | Note Added: 0018182 | |
| 2014-06-05 17:03 | tmcarthur | Status | feedback => closed |
| 2014-06-05 17:04 | tmcarthur | Assigned To | => tmcarthur |
| 2014-06-05 17:04 | tmcarthur | Resolution | open => fixed |
| 2014-06-05 17:04 | tmcarthur | Fixed in Version | => 3.4-alpha1 |
