Since we are in the spirit of fixing modes... what about with regards to the channel private (+p) and secret modes (+s). They are no longer different but exactly the same. Perhaps changing +p to its original function or removing it, in its entirety would be an idea.
Thanks
Kookaburra/Adam
What do you suggest the difference should be? Traditionally, the difference is the following: When a channel is +p, it does not show up in /LIST, but instead shows up in /LIST, /NAMES, /TOPIC, /WHO commands, etc with the name replaced with "Prv", and the topic hidden, unless the one issuing the command is a member of the channel.
When a channel is +s, it does not show up in /LIST, /NAMES, /WHOIS, etc, at all, except to members of the channel.
The /MODE command is a special case, and traditionally channel MODE status can be queried of +p and +s channels at all times by non-members for obvious reasons (but a key set by +k, cannot be seen by users who are not joined to the channel).
In practice, these differences between +p and +s are sufficient to make them both satisfy the function, and "Prv" entries showing up in /LIST and /WHO are an annoyance.
There's no real legitimate reason to know how many private channels you can't see a user is joined to, and there's even fewer reasons to see a "* Prv" entry in /LIST indicating the number of entries you can't access
If you want to know number of total channels, /LUSERS is more appropriate, but again, +s channels traditionally don't count towards LUSERS numbers, whereas +p channels do.
So if +p should do something different, what's the most useful thing for it to do, and is that thing actually worth it?
I can imagine schemes, such as "other users can /WHOIS or /WHO you and see what +p channels you are in", BUT +p channels are hidden from /LIST.
*i.e. A way of reducing visibility of large channels, but still allowing knowledge to spread by word-of-mouth.. it's not "secret", we just don't want to encourage random joiners too much.
Or the opposite.. Perhaps you want a channel to show in /LIST, and be otherwise, fully visible, but the channel could be such that users would be embarrased to have it in their /WHOIS line, for various reasons.
In any event, for it to be useful, the definition must be crystal clear, and it should meet user expectations as best as possible....
-- -J
2009/3/16 Adam Koeller dalnet.kookaburra@gmail.com:
Since we are in the spirit of fixing modes... what about with regards to the channel private (+p) and secret modes (+s). They are no longer different but exactly the same. Perhaps changing +p to its original function or removing it, in its entirety would be an idea.
Adam Koeller wrote:
Since we are in the spirit of fixing modes... what about with regards to the channel private (+p) and secret modes (+s). They are no longer different but exactly the same. Perhaps changing +p to its original > function or removing it, in its entirety would be an idea.
They're not exactly the same but perhaps it's time to have cmode +p hide the channel completely from /list again (but still showing the channel on /whois). This will help channels who don't appreciate the random spambots that use /list to find them.
-Kobi_S.
Here's a thought: I wonder about the scalability of /LIST on todays IRC networks which have 5000+ channels at a time, it's so unreasonably large that it is pretty impractical for a human to find anything in /list, unless they apply some kind of filtering, after they just consumed heavy resources just to download the full listing.
It's about as useful for legitimate uses as a flat '/who 0'.... Imagine if usenet had had a flat hierarchy like this. Limiting /LIST to channels with 2+ members, doesn't filter all that much, and limiting to larger channels perhaps makes /LIST even more useless, since the person may be looking for a channel that happens to have 9 members, instead of the 10 you might pick for /LIST filtering.
Perhaps the LIST command should go away entirely and be replaced with a notice to check some URL for a HTTP-based search service.
(Not a HTTP port opened by ircd, but a standalone module -- some service the server admin would be expected or anticipated to run as a separate process, that would have only read-only access to online IRCD data structures.)
Or with some sort of category-based listing system. Where /LIST contents are approved by humans, so they meet some sort of basic standard.
The average person isn't going to figure out /LIST advanced syntax, they'll try (the hard way) to find anything useful in there.
So I would think it better to take away the inferior tool entirely and provide a robust complete and superior replacement mechanism for accomplishing the goal of finding a channel.
Possibly have /LIST show a _small_ number of highly popular channels that had to go through an extensive application process and be human-approved. _And_ a pointer to a web site for more detailed searches of channels currently online.
Oh, and +p channels wouldn't be searchable in that manner.
On Wed, Apr 15, 2009 at 6:06 PM, Kobi Shmueli kobi@dal.net wrote:
Adam Koeller wrote: They're not exactly the same but perhaps it's time to have cmode +p hide the channel completely from /list again (but still showing the channel on /whois). This will help channels who don't appreciate the random spambots that use /list to find them.
-- -J
/LIST is part of the RFC for IRC. The behavior it is to display is pretty well defined and understood by IRC clients.
On Thu, Apr 16, 2009 at 12:49 AM, James Hess mysidia@gmail.com wrote:
Here's a thought: I wonder about the scalability of /LIST on todays IRC networks which have 5000+ channels at a time, it's so unreasonably large that it is pretty impractical for a human to find anything in /list, unless they apply some kind of filtering, after they just consumed heavy resources just to download the full listing.
It's about as useful for legitimate uses as a flat '/who 0'.... Imagine if usenet had had a flat hierarchy like this. Limiting /LIST to channels with 2+ members, doesn't filter all that much, and limiting to larger channels perhaps makes /LIST even more useless, since the person may be looking for a channel that happens to have 9 members, instead of the 10 you might pick for /LIST filtering.
Perhaps the LIST command should go away entirely and be replaced with a notice to check some URL for a HTTP-based search service.
(Not a HTTP port opened by ircd, but a standalone module -- some service the server admin would be expected or anticipated to run as a separate process, that would have only read-only access to online IRCD data structures.)
Or with some sort of category-based listing system. Where /LIST contents are approved by humans, so they meet some sort of basic standard.
The average person isn't going to figure out /LIST advanced syntax, they'll try (the hard way) to find anything useful in there.
So I would think it better to take away the inferior tool entirely and provide a robust complete and superior replacement mechanism for accomplishing the goal of finding a channel.
Possibly have /LIST show a _small_ number of highly popular channels that had to go through an extensive application process and be human-approved. _And_ a pointer to a web site for more detailed searches of channels currently online.
Oh, and +p channels wouldn't be searchable in that manner.
On Wed, Apr 15, 2009 at 6:06 PM, Kobi Shmueli kobi@dal.net wrote:
Adam Koeller wrote: They're not exactly the same but perhaps it's time to have cmode +p hide
the
channel completely from /list again (but still showing the channel on /whois). This will help channels who don't appreciate the random spambots that use /list to find them.
-- -J _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
/LIST is part of the RFC for IRC. The behavior it is to display is pretty well defined and understood by IRC clients.
On Thu, Apr 16, 2009 at 12:49 AM, James Hess mysidia@gmail.com wrote:
Here's a thought: I wonder about the scalability of /LIST on todays IRC networks which have 5000+ channels at a time, it's so unreasonably large that it is pretty impractical for a human to find anything in /list"
---------------------------------------------------------------------------- ------------------------------------------------------------
In the days before the DDOS attacks of some 5 maybe 6 years ago, DALnet had in excess of 30,000 channels, I never had a problem with /list, always found what i was looking for, plus EG: /list *aus* or /list *chat* etc filters the channel list somewhat.
Ozlion/lionel
Join me in my chat room at #auschats on DALnet http://www.mirc.com/
#auschats channel forum http://forumforfree.com/auschats.html
#auschats stats pages http://www.ozlion.com/auschats.html
On Thu, Apr 16, 2009 at 9:29 AM, Vin King vin.king@gmail.com wrote:
/LIST is part of the RFC for IRC. The behavior it is to display is pretty well defined and understood by IRC clients.
There are no IETF standards for IRC. There are really no common written standards for IRC accepted by the internet community, only de-facto standards. The only RFC documents available describe how one of the original implementations of IRC worked, and they are outdated in many ways.
It would be great if a full-fleshed standard could be developed, and have the technical community consensus required for accepted, but unfortunately, for IRC, that has not happened.
IRC clients can handle a lot of things that not all servers will support.
Removing /LIST entirely across the board might not be a good strategy, but there's nothing wrong with that approach as far as "standards" are concerned. Faking a blank /LIST and sending the user an error message in the form of a server notice is not a difficult feat...
-- -J
On Fri, Apr 17, 2009 at 12:52 AM, James Hess mysidia@gmail.com wrote:
There are no IETF standards for IRC. There are really no common written standards for IRC accepted by the internet community, only de-facto standards. The only RFC documents available describe how one of the original implementations of IRC worked, and they are outdated in many ways.
This is pretty wrong, actually. RFC1459 is still used as a basis for client-side protocols. We can mess with a few things here and there, based on the flexibility that the RFC gives us, but by and large, we try not to actually break it. Lucky for us, the RFC doesn't place a lot of limitations on things.
It would be great if a full-fleshed standard could be developed, and have the technical community consensus required for accepted, but unfortunately, for IRC, that has not happened.
This has been tried, several times. The fact is that the community is sufficiently splintered between networks and software (both client and server, not to mention different approaches to services) that nobody could agree on anything. At one point we got as far as a draft for a protocol _negotiation_ extension, that would allow us to negotiate different protocols between clients and servers, but that draft died.
The only thing we managed to get out of that 18 month collaboration was the use of the 005 numeric to advertise optional features. And even that was just a vaguely defined set of key/value pairs that could safely be completely ignored by the client.
I've personally come to the conclusion that the client protocol battle simply isn't worth fighting, and am concentrating on making the network and network protocols more resilient.
In the context of this conversation though, altering the LIST output can be done without breaking clients. We can't do nested 'categories', but we can decide what list we send the users.
-epi
Greetings,
On Thu, Apr 16, 2009 at 12:49 AM, James Hess mysidia@gmail.com wrote:
I wonder about the scalability of /LIST on todays IRC networks which have 5000+ channels at a time, it's so unreasonably large that it is pretty impractical for a human to find anything in /list, unless they apply some kind of filtering, after they just consumed heavy resources just to download the full listing.
There are actually functions within the LIST command to do that filtering at the server, as you mention later on....
Or with some sort of category-based listing system. Where /LIST contents are approved by humans, so they meet some sort of basic standard.
We did discuss this one in depth a few years ago. I think we may have actually coded part of it up as well, but there were a lot of political issues with rolling it out. At that point, the ethical questions came into play as to what would qualify for the list, and how it would be administered. The conversation just died out, as I recall, but its definitely worth considering reopening. If someone were to write up a patch implementing it, I would definitely consider merging it. There would have to be some discussions within the dalnet administration about actually using it, obviously, as well as the services support to do it as well.
So I would think it better to take away the inferior tool entirely and provide a robust complete and superior replacement mechanism for accomplishing the goal of finding a channel.
Agreed. If you write it, I'll review it. :)
-epi
-
Aaron Wiebe -
Adam Koeller -
James Hess -
Kobi Shmueli -
lionel -
Vin King