View Issue Details

IDProjectCategoryView StatusLast Update
0004160unrealircdpublic2014-06-05 17:04
ReportersyzopAssigned Totmcarthur 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version 
Target Version3.4-alpha1Fixed in Version3.4-alpha1 
Summary0004160: Channel mode +u/+mu
DescriptionSimple 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.
TagsNo tags attached.
3rd party modules

Relationships

related to 0003344 closedsyzop +u auditorium mode 
related to 0001750 closedsyzop Erratic Auditorium Mode (+u) Behaviour 
related to 0002160 closedsyzop Channel +u Ops 
related to 0002216 resolvedsyzop More documentation for channel mode +u 
related to 0003348 closedsyzop +mu suggestion 
related to 0003682 closedsyzop Channel mode +u with +m causes certain issues 
related to 0003985 closedsyzop Channel Mode Request +u & +U 
related to 0004067 closedsyzop Make mode +u shows Halfops and Voices 
related to 0001051 closedsyzop Make chmode +u more client/user-friendly 

Activities

Shining Phoenix

2013-01-09 21:48

reporter   ~0017344

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.

Stealth

2013-01-10 00:42

reporter   ~0017346

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).

Stealth

2013-01-10 00:43

reporter   ~0017347

As for channel list updates, sending a NAMES out of the blue would work, but it would be cleaner to send proper JOIN/PART

katsklaw

2013-01-13 20:44

reporter   ~0017353

Last edited: 2013-01-13 20:45

View 2 revisions

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.

Shining Phoenix

2013-01-13 22:07

reporter   ~0017354

The JOIN/PART would only be a flood issue if opping/deopping was a flood itself, right?

nenolod

2013-01-14 08:18

reporter   ~0017355

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).

katsklaw

2013-01-16 02:14

reporter   ~0017381

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.

Shining Phoenix

2013-01-16 04:04

reporter   ~0017382

Good point.

syzop

2013-05-26 11:16

administrator   ~0017687

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. )

syzop

2013-05-26 11:23

administrator   ~0017688

Last edited: 2013-05-26 11:26

View 3 revisions

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?

ShawnSmith

2014-06-02 22:42

reporter   ~0018167

"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.

tmcarthur

2014-06-05 17:03

developer   ~0018182

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.

Issue History

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 View Revisions
2013-01-13 22:07 Shining Phoenix Note Added: 0017354
2013-01-14 08:18 nenolod 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 View Revisions
2013-05-26 11:26 syzop Note Edited: 0017688 View Revisions
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