[Pidgin] #15090: freenode's new +q numeric (728) is unrecognized

[Pidgin]

#15090: freenode's new +q numeric (728) is unrecognized
---------------------+------------------------------------------------------
 Reporter:  marienz  |        Owner:  elb
     Type:  defect   |       Status:  new
Milestone:           |    Component:  IRC
  Version:  2.10.3   |   Resolution:     
 Keywords:           |  
---------------------+------------------------------------------------------

Comment(by marienz):

 Replying to [comment:1 elb]:
 > The problem is that, for this, as in all the other numerics that
 freenode just ''randomly made up'',

 Our ircd is based on charybdis, and this new numeric was inherited from
 them. Any recent charybdis-based ircd (with quiets enabled) will use it
 too. I have asked them to clarify why they picked this, and was told this
 one should not collide with anything else currently in use, but is (so
 far) charybdis-specific. It's unfortunately not the same one OFTC uses, as
 their choice collides with an ircnet numeric.

 > it's often hard to tell exactly where the message belongs.

 If the command following the prefix is three digits, and the second
 argument after that is a channel the client is on, you can be fairly
 certain displaying the message in that channel's window/tab would be
 reasonable. Clients really do make use of this (see for example the
 "default" branch in proto-irc.c:process_numeric in xchat).

 >  Even irssi prints this message to the server messages window, and
 doesn't know to put it in the channel.

 This is unfortunately correct for older irssis. Newer irssis use
 event_target_received for 728/729, which does what I describe above.

 >  This is one price of stapling random crap onto the protocol with no
 documentation, rhyme, or reason.  We have special cased several freenode
 numerics over the years, but they change -- +q alone has been handled at
 least three or four different ways since I have been using Freenode.
 (Though this might be its first wholly separate numeric, rather than
 changing mode letter or ban pattern, I'm not sure.)

 The change was announced on http://blog.freenode.net/2011/09/ircd-
 upgrades/ , which we advertised a bunch (through wallops, possibly even
 globals) shortly before those upgrades happened. The charybdis NEWS file
 also mentions the change. We've never had much luck getting people to
 respond to our requests for testing, and we tend to not personally test
 all IRC clients (especially ones that fit our own usage patterns as poorly
 as things like Pidgin do). I don't see how to improve this situation.
 Perhaps we should gather some usage statistics and personally test the
 popular ones prior to upgrades, but I do not have high hopes of that
 happening given time constraints.

 I believe the reason for the change was to make it easier for clients that
 request the +b and +q list at the same time to see which is which (the
 367/368 numeric for the normal banlist does not include the mode
 character).

 Also note that several client messages have a final component that is
 human-readable english text, for the benefit of clients that do not
 explicitly support this message.

 > As you may or may not know, Pidgin does not have a server messages
 window, as it does not really fit anywhere in the Pidgin UI.  This causes
 a problem for us for trapping arbitrary messages to someplace the user can
 see them.  The debug window is an unfortunate and poor catch-all, there's
 no question about that.

 Right, but dealing with this by making a lot of information impossible to
 get at, even if requested by the client explicitly, makes for a poor user
 experience and is making you tremendously impopular with network staff (at
 least on freenode, but I doubt it's just us). We really do expect people
 to be able to see the MOTD ''somewhere'', for example, at least when they
 ask for it explicitly (there are some notices in there that we need people
 to be able to read). "/motd" and "/quote motd" does not work
 ("Unrecognized command" for the former, the latter had no visible effect
 as Pidgin helpfully swallowed all MOTD content).

 > Pidgin is not, and likely will never be, a "power user" IRC client.
 Part of this is simply because its interface is geared toward IM-style
 messaging, not IRC-style messaging.  We are comfortable with this
 limitation, although why try to mitigate its particularly wild excesses
 where possible.

 ''You'' may be comfortable with it, but we get a fair number of people
 trying to actually use Pidgin as an IRC client, or use Pidgin as a channel
 op, and get very confused. The complete dropping of unrecognized messages
 makes this ''more'' confusing, not less. I'd argue that if you do not wish
 to support such things you should not implement commands like /mode (which
 can take any mode character) and /quote (obvious).

 > The "right" solution to this, insomuch as there is a right solution, is
 probably to add an explicit 728 handler.  We do not like to add handlers
 for made-up numerics, for two primary reasons: 1) it can be the case, and
 ''has been'' the case in the past, that different networks use the same
 numeric for different purposes, with no good way to differentiate;

 The numeric the charybdis developers picked for this should not collide
 with anything in popular use today (although obviously that's no guarantee
 for the future...)

 > and 2) networks like to change their made-up numerics more often than
 their ops change underwear.

 freenode ircd upgrades (which introduce such numerics changes) occur
 infrequently (think one a year).

 > However, we have certainly conceded this in the past, when a network
 mistakenly chooses to make up a numeric for a particularly importantt
 feature.  I will consider it for +q.  (As you mention, we have added
 explicit handlers for made-up critical info status numerics for Freenode
 in the past.)

 These are usually added or changed to make it possible for clients to tell
 certain messages apart, assuming that clients that do not recognize them
 will still display them. If you just show these messages ''somewhere''
 (which can be as terrible as "the most recently active IRC channel or
 query tab/window", although I believe it'd be better to attempt to use the
 2nd argument as a channel name as mentioned above) I would consider it a
 vast improvement.

 > As to whether it is in fact the client or the network that is broken,
 that is certainly a matter of perspective.

 The only other client I am aware of that completely hides away
 unrecognized messages is empathy, and I'm about to file a bug there. I've
 asked around and have not been able to find any others. Make of that what
 you will.

 Apart from getting this specific bug fixed I'm also trying to break the
 cycle of #freenode helpers telling people to use a "proper" client instead
 of Pidgin, and Pidgin users insisting Pidgin is an IRC client and should
 be usable by channel ops. If this is not a use case you care about (which
 given Pidgin being primarily an IM client would make sense, in my opinion)
 an explicit drop of some of your channel op features would make our life
 easier.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/15090#comment:2>
Pidgin <http://pidgin.im>
Pidgin