View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001750 | unreal | ircd | public | 2004-04-21 01:34 | 2013-01-09 10:43 |
| Reporter | Dabljuh | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Platform | X86 / All? | OS | Linux | OS Version | 2.4.20 |
| Product Version | 3.2-RC1 | ||||
| Summary | 0001750: Erratic Auditorium Mode (+u) Behaviour | ||||
| Description | The Auditorium Mode behaves erratic. I can think of two basic ways to make such a mode behave like. I call these two modes 'temporary invisibility' and 'complete invisibility'. In 'temporary invisibility', an user would be invisible in the channel until he says something. On the first text message, mode change or whatever gives away the presence of an user, a 'join' is pretended/summoned so the client's channel list gets updated, and in the following the user is or is not displayed at successive /who's. Eventually after a certain time of inactivity or for some other reason a 'part' can be summoned / pretended to hide the user again, that in fact still stays in the channel. Ops or halfops could be excempt from the limitations. this mode is used for example on the IRCD that Quakenet uses. In 'Complete Invisibility' Mode, however, people remain invisible (as in, not showing up in the names list) indefinitely. with the exception for the ops that see all joins and all parts, but do not receive a complete channel list either. This is the way Unrealircd seems to work. I am not saying either of these modes is superior over the other. Although the latter is possibly harder to implement properly and logically, eventually to the point of where it is impossible to sustain this mode without violating standardized IRC client/server behaviour. They are just modes by convention. many modes in between are imaginable. The unrealircd rc1 auditorium mode however behaves slightly erratic. People who are opped do not receive a complete channel list (impossible to implement?) nor do people who receive ops show up in the channel list of people who are already in the channel, to see the new ops, they need to /cycle the respective channel. I request that auditorium mode gets fixed before the final release. Because of the difficulty continuing the complete invisibility model, I suggest you switch for an, in my opinion, more easily implementable temporary invisibility model. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
You mentioned RC1. It's now outdated, go get RC2-fix. The problem might have been solved there. |
|
|
There's nothing in the changelog of rc2-fix that looks like it, and I can't afford to restart the server every 5 minutes. |
|
|
This certainly would not be changed before 3.2 final, we are in a total feature freeze / non-RC bug freeze. Anyway, what you just described is on the TODO list of codemastr (the quakenet idea or similar IIRC). |
|
|
The 'complete invisibility' thing may need to stay in some part because of what happens when you put +m and +u together... |
|
|
yup... or if they cannot talk -> never talk -> no join... or ah well... it's fun, and I'm going to think of it! ha! ;). edited on: 2004-04-21 18:35 |
|
|
Heres the way it *should* work: User joins channel... Only ops (and the person joining) see the JOIN. When ops do a NAMES, it shows all users. When non-ops do a NAMES, it shows ops only. When an op says something, all can see. When a non-op says something, only ops can see. When a user is opped, ops see the MODE +o When a user is opped, non-ops see a JOIN and then a MODE +o When a user is deopped, ops see the MODE -o When a user is deopped, non-ops see a MODE -o and then a PART Likewise, when a non-op PARTs or is KICKed, only ops see the message. The only time a non-op should be aware of the presence of another non-op in an auditorium channel is if the channel is -t and they set the TOPIC or are invited. |
|
|
That would be good for +mu channels, but +u-m is different, becuase non-op messages will be seen as normal. Also, how would +v users be handled in this case? |
|
|
I've thought through it and I don't think its possible to do it in a consistent and conformant way without some sort of virtual list. +u is just one tiny, little mode, and should have the least possible effect. Too bad there isn't anything in the RFC. But that the RFC isn't the cure for all shows the +p and +s problem - This simply doesn't make sense. Personally, I would prefer to violate the RFC there, just to do it in a way that makes SENSE. There is not one single right way to do a decent, useful mode +u. We need to think through it and talk it through. I like the way it works on quakenet for example (see #tutorial and #c++ there) but that doesn't mean that is the only right way. First of all, we probably need to establish: WHAT IS MODE +u GOOD FOR? Personally, I was thinking of an adult chat were people can announce their 'desires', but not getting a query open just entering the channel. |
|
|
So is this being worked on or not? |
|
|
Personally, I think the current implementation works alright, as for breaking clients, do <IRC> username: message (unreal already does this under some circumstances, i forget what they are) |
|
|
Bump. Still an issue? |
|
|
I recall nothing on this matter being changed. So I would dare say it is still an issue. |
|
|
Discussion moved to 0004160 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-04-21 01:34 | Dabljuh | New Issue | |
| 2004-04-21 02:41 | Ron2K | Note Added: 0005898 | |
| 2004-04-21 03:35 | Dabljuh | Note Added: 0005899 | |
| 2004-04-21 10:16 | syzop | Note Added: 0005901 | |
| 2004-04-21 18:10 | aquanight | Note Added: 0005904 | |
| 2004-04-21 18:34 | syzop | Note Added: 0005905 | |
| 2004-04-21 18:35 | syzop | Note Edited: 0005905 | |
| 2004-04-29 01:53 | olene | Note Added: 0005942 | |
| 2004-04-29 09:41 | aquanight | Note Added: 0005951 | |
| 2004-04-29 13:12 | Dabljuh | Note Added: 0005953 | |
| 2004-11-25 00:25 |
|
Relationship added | related to 0002160 |
| 2005-03-09 06:04 | Dabljuh | Note Added: 0009543 | |
| 2005-03-12 13:19 | JasonTik | Note Added: 0009569 | |
| 2007-04-27 05:51 |
|
Note Added: 0013844 | |
| 2007-04-27 05:51 |
|
Status | new => feedback |
| 2007-05-17 20:14 | aquanight | Relationship added | related to 0003344 |
| 2007-05-17 20:15 | aquanight | Note Added: 0014157 | |
| 2007-05-17 20:15 | aquanight | Status | feedback => acknowledged |
| 2013-01-09 10:40 | syzop | Relationship added | related to 0004160 |
| 2013-01-09 10:42 | syzop | Note Added: 0017327 | |
| 2013-01-09 10:42 | syzop | Status | acknowledged => closed |
| 2013-01-09 10:43 | syzop | Assigned To | => syzop |
| 2013-01-09 10:43 | syzop | Resolution | open => duplicate |
