View Issue Details

IDProjectCategoryView StatusLast Update
0002906unrealmodule apipublic2014-06-04 10:17
ReporterTranqer Assigned Totmcarthur  
Status resolvedResolutionfixed 
OSRedhatOS Version4.0ES 
Product Version3.2.4 
Fixed in Version3.4-alpha1 
Summary0002906: Feature request : Asuka channel mode +D/+d
DescriptionThis description comes from the Asuka docs:

* Channel mode +D and +d
     'Delayed join' mode, when set on a channel joins and parts for that
     channel are squelched. A user will be 'invisible' in the channel
     from other users until they speak, are opped/voiced or change the
     topic. When the +D mode is cleared, 'invisible' users will not be
     revealed, instead the +d mode will automatically be set by the ircd
     if invisible users remain in the channel. +d will be automatically
     removed when the last 'invisible' user either becomes visible or
     leaves the channel. It is possible to see the 'invisible' users
     on a channel by doing /NAMES -d.

This could be done by module..I think, but it would be nice to have it standard in unreal. A lot of users switching from Quakenet (or any other network usuing Asuka) to smaller networks using unreal have requested this mode before. And I'm sure there are a lot more people interested in this :)
TagsNo tags attached.
3rd party modules


child of 0003284 closedsyzop 3rd Party Module Wishlist 



2006-05-16 10:49

reporter   ~0011708

what is the point of this mode?


2006-05-16 13:49

reporter   ~0011709

White_Magic: The entire point of it is explained above.
It makes joins/parts on a big channel (say 200+ users) invisible so you can actually speak with each other without having more green than black on your screen.


2006-05-16 22:23

reporter   ~0011710

I think +u comes close to doing this mode. Even though it is designed to hide all user, it will still definately stop join/part messages, while leaving the users the ability to talk


2006-05-17 02:14

reporter   ~0011714

Yes, it indeed comes very close, although its not the most perfect solution I was looking for.

I suppose +D will never be really added to Unreal, so I'm hoping someone is willing/able to make a module for it :)


2006-05-18 05:31

administrator   ~0011725

I could be mistaken, but.. IIRC codemastr did think about changing +u to this way. Because it would make things more clean, and well.. logical.
From a non-coding standpoint I also find it nice, I suppose it's a hell to code though, but have not looked into it ;). (Then again.. we have had worse things..)


2006-05-18 15:59

reporter   ~0011726

Well, I would appreciate it very much if it would be coded someday. :)
And I think a lot of others will like it as well.. :)

Thanks for the respons, syzop.

Shining Phoenix

2007-04-26 01:00

reporter   ~0013710

Hmm...or you could make a channel mode to hide all JOIN, PART and QUIT, and send the names list to all users whenever someone join/part/quits. That way there is no invisibility garbage, and no join/part/quit lines either.


2007-04-26 02:17

reporter   ~0013712

I really like the idea of ircu's +D mode.
It's meant for big channels and if you have to send on every join/part/quit all nicks in the channel where >200 users are in, it's a real waste of traffic


2007-06-12 15:14

reporter   ~0014343

I'm moving this to 3rd party module wishlist for now, may be picked up later during development process.


2007-06-12 15:28

reporter   ~0014347

Last edited: 2007-06-12 15:30

This is good idea.I am agree with penna and the others who see this as suitable.


2013-05-26 11:24

administrator   ~0017689

Last edited: 2013-05-26 11:26

View 3 revisions

** cross post from 0004160 **
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?


2013-05-30 17:39

reporter   ~0017699

From what I've seen in ircu's code +D/+d isn't that hard to implement, you just have to make sure that if the user is still delayed and parts/quits, nothing is shown, and when the user speaks, changes topic, gets a status mode or otherwise interacts with the channel in a way other then part/join/quit then the delayed join is shown. The only problem with ircu's +D/+d implementation is it allows users to join the channel unseen even by channel ops and can then observe the channel. Not to mention channel ops then have no way to even list delayed users in the channel. So that's something I'd say UnrealIRCd would need to account for, even if it's a special related command (doing it with NAMES #channel would in some cases update the users' clients nick list and then if the delayed user left wouldn't get updated again)


2013-06-03 13:33

administrator   ~0017702

Last edited: 2013-06-03 13:34

View 2 revisions

I've not looked into this, but.. I presume the purpose of +d/+D is to hide all delay the join/part/quit stuff (save bandwidth & prevent screen from being filled) and not to hide users, right? So /WHO #channel will show all users? And /WHOIS shows the channel as well? (obeying any +p/+s rules)

Anyway, I'd say +o (or +h) and higher should see all users joining / parting. Without it, it's substantially harder to do your channel management tasks. Does anyone object?


2014-05-30 18:06

reporter   ~0018148

Looking at getting this in 3.4. Thanks.


2014-06-02 13:06

reporter   ~0018161

This is kinda pointless as clients such as mirc / adiirc (similar to mirc but free), you can forward join/part/quit notices to Status window from the Options dialog, and write scripts for xchat which does the same thing.

Agreed with +o being able to see join/part/quit, however, I'd also add if the operator is de-opped then they will not see them perhaps, and if they re-op then they will see them again, just my 2 cents.


2014-06-02 21:33

reporter   ~0018166

Last edited: 2014-06-02 22:07

View 5 revisions

Instead of making this a channel mode, I think it'd be better suited as a usermode. This way users who want to hide joins/parts/quits can enable it and those who don't can let their client handle it as it usually does.

Personally, I don't see the need for this mode at all since many recent clients have the ability to filter out these things. Ex: WeeChat's smartfilter

Edit :: These kind of modes also interfere with client-side filtering of things. WeeChat's smartfilter will hide the join until unless the user speaks within a certain amount of time of their join (default: 5 minuets). Now if you hide the join until just before the user speaks, you're effectively killing the smart filter because it doesn't know the actual time of the join.

Also, as a bit of an after-thought, these modes are worse than client-side filtering.

Let's say you're idling on a 100 user channel, and you idle long enough so that people quit and rejoin, but you don't actually see the rejoin due to the delayed mode. Now you ask a question and are suddenly flooded with:

PRIVMSG derp: What do you all think of this new feature <X>?
JOIN: derp1 (Actual join time: 3 days ago)
PRIVMSG derp1: somestuff
JOIN: derp2 (Actual join time: 30 seconds ago)
PRIVMSG derp2: somemore stuff
JOIN: derp3 (Actual join time: 5 hours ago)
PRIVMSG derp3: Somemore stuff

You can't just not send the joins, regardless of how long ago the user actually joined, because the client wouldn't be synced correctly. Client-side filtering of this situation would allow you to still send the joins as normal, but have them hidden from view if they do not speak within so many minutes of their join.

Same situation as above, with client-side filtering instead:

JOIN: derp2 (Client unhides the join where it would have appeared had it not been hidden by the smart filter, due to the user speaking within so many minutes of the join)
PRIVMSG derp: What do you all think of this new feature <X>?
PRIVMSG derp1: somestuff
PRIVMSG derp2: somemore stuff
PRIVMSG derp3: Somemore stuff

Edit 2 :: Removed pictures, will reupload if I find a better screenshot.


2014-06-03 18:44

administrator   ~0018168

The discussion period, which has been like 8 years, has passed. +d/+D is already being implemented, in fact it will be committed very soon.
Once that's done, this bug will be closed and you can have a look at it.

That doesn't mean you can't still create another system, like a user mode, or whatever, but for that you better create a new bug report to discuss.


2014-06-03 20:51

reporter   ~0018169

Preparing to commit, pending final testing and CR.


2014-06-03 22:10

reporter   ~0018172

tmcarthur: Can you take a look at this feature request?

It has to do with the delayjoin, it's a usermode to negate the function of it for users who don't want server-side filtering.


2014-06-04 08:34

reporter   ~0018176

ShawnSmith: I have some concerns about that - I've noted them in that bug - we can continue discussion there - the patch for this is done and tested, I'll be committing it shortly.



2014-06-04 10:16

reporter   ~0018180

There are a few other modifications we may want to do in the future, but the v1 of this is in unreal34 branch - I'll do some additional testing to make sure we didn't miss anything over next few days

Issue History

Date Modified Username Field Change
2006-05-09 07:14 Tranqer New Issue
2006-05-16 10:49 White_Magic Note Added: 0011708
2006-05-16 13:49 Tranqer Note Added: 0011709
2006-05-16 22:23 Stealth Note Added: 0011710
2006-05-17 02:14 Tranqer Note Added: 0011714
2006-05-18 05:31 syzop Note Added: 0011725
2006-05-18 15:59 Tranqer Note Added: 0011726
2007-04-26 01:00 Shining Phoenix Note Added: 0013710
2007-04-26 02:17 penna Note Added: 0013712
2007-04-26 06:32 stskeeps Status new => acknowledged
2007-06-12 15:14 stskeeps Note Added: 0014343
2007-06-12 15:15 stskeeps Relationship added child of 0003284
2007-06-12 15:28 totalsolid Note Added: 0014347
2007-06-12 15:29 totalsolid Note Edited: 0014347
2007-06-12 15:30 totalsolid Note Edited: 0014347
2013-05-26 11:24 syzop Note Added: 0017689
2013-05-26 11:25 syzop Note Edited: 0017689 View Revisions
2013-05-26 11:26 syzop Note Edited: 0017689 View Revisions
2013-05-30 17:39 Jobe Note Added: 0017699
2013-06-03 13:33 syzop Note Added: 0017702
2013-06-03 13:34 syzop Note Edited: 0017702 View Revisions
2014-03-14 01:14 peterkingalexander Issue cloned: 0004300
2014-05-30 18:06 tmcarthur Note Added: 0018148
2014-05-30 18:06 tmcarthur Assigned To => tmcarthur
2014-05-30 18:06 tmcarthur Status acknowledged => assigned
2014-06-02 13:06 Amiga600 Note Added: 0018161
2014-06-02 21:33 ShawnSmith Note Added: 0018166
2014-06-02 21:50 ShawnSmith Note Edited: 0018166 View Revisions
2014-06-02 21:54 ShawnSmith Note Edited: 0018166 View Revisions
2014-06-02 21:55 ShawnSmith Note Edited: 0018166 View Revisions
2014-06-02 22:07 ShawnSmith Note Edited: 0018166 View Revisions
2014-06-03 18:44 syzop Note Added: 0018168
2014-06-03 20:51 tmcarthur Note Added: 0018169
2014-06-03 22:10 ShawnSmith Note Added: 0018172
2014-06-04 08:34 tmcarthur Note Added: 0018176
2014-06-04 10:16 tmcarthur Note Added: 0018180
2014-06-04 10:16 tmcarthur Status assigned => resolved
2014-06-04 10:16 tmcarthur Fixed in Version => 3.4-alpha1
2014-06-04 10:16 tmcarthur Resolution open => fixed
2017-01-06 15:48 syzop Category module => module api