add private channels in the form of a module Channel::Private, like Channel::Secret

• Complex PRIVMSG
  a status character ('@'/'+') followed by a channel name, to send to users
  with that status or higher only.
  capab: CHW
  propagation: all servers with -D users with appropriate status
• Complex PRIVMSG
  '=' followed by a channel name, to send to chanops only, for cmode +z.
  capab: CHW and EOPMOD
  propagation: all servers with -D chanops
• Complex PRIVMSG
  a user@server message, to send to users on a specific server. The exact
  meaning of the part before the '@' is not prescribed, except that "opers"
  allows IRC operators to send to all IRC operators on the server in an
  unspecified format.
  propagation: one-to-one
• Complex PRIVMSG
  a message to all users on server names matching a mask ('$$' followed by mask)
  propagation: broadcast
  Only allowed to IRC operators.
• Complex PRIVMSG
  a message to all users with hostnames matching a mask ('$#' followed by mask).
  Note that this is often implemented poorly.
  propagation: broadcast
  Only allowed to IRC operators.

server initialization complete... but not connect /server ip:6667

Test client http://nirc.herokuapp.com/

TS6 spec says not to propagate the topic burst message if the topic is equal to the current one.

Error Start Ubuntu 12.04 Lts

perl 5, version 14

Need to make a utils function which combines $user->server_notice() and notice() and another which uses gnotice(). The functions will send out server notice as normal except, if the provided user is not opered and/or does not have the notice flag, he will still receive the notice. For opers it will appear like notice(), e.g. *** Notice: Reload: ...; but for non-opers it will appear like ->server_notice(), e.g. *** Reload: ....

SASL only ever worked with the built in account mechanisms. It needs to be supported in a more generic way that would work for modules implementing accounts as well as external services.

I think this used to be provided by the Account module which has been removed. Needs to be generic and work for any account implementation.

Indicated in RPL_ISUPPORT as ELIST. See http://www.irc.org/tech_docs/005.html

JELP sends out channel creation as two messages, JOIN and then CMODE. We should do it the way TS does, use the same command as during burst. CUM is analogous to SJOIN; we can use that and eliminate the join_with_modes outgoing command (and use the channel_burst for channel creation).

Needs to be configurable. Needs to be reflected in RPL_ISUPPORT.

default.conf is getting enormous due to copy+pasted TS6 mode and prefix definitions. Need to make some sort of base set or to move these definitions to modules/TS6/TS6.module/modes.conf.

Needs to be configurable. Needs to be reflected in RPL_ISUPPORT.

It is sent correctly, and charybdis sends the MODE message to users. It's just not being enforced somehow

This is caused by storing which servers we've checked rather than to which locations we've sent. But we have to do that because JELP RELOAD uses SIDs rather than server masks. I think I need to send out a single RELOAD with a server mask or maybe with a list of SIDs. And of course, only send it to the matching server(s).

• Add mode block and definitions
• Do not send channel messages to deaf users
• Do not send channel PRIVMSG messages to servers unless there is at least one non-deaf user

Problem

There is no global limit for how many targets a multi-target command can have. Each command currently implements this differently: some have no limit, some have hardcoded limits, and some do not even support more than one target when they should.

Desired behavior

The target limit needs to be universal among all multi-target commands and configurable by limit:target. It should be reflected in RPL_ISUPPORT as MAXTARGETS (Currently, this is hardcoded to one, for compatibility with the commands which do not properly support multiple targets). Excess targets should be ignored.

Implementation

I think this should be implemented in the parameter parser. As it presently exists, commands with a single channel target use the channel parameter type. We could add channels which will look up a comma-separated list of channels and push an array reference of channel objects to the parameter list. If a channel does not exist, send out ERR_NOSUCHCHANNEL and skip it. If the target limit as specified by limit:target is reached, ignore the remainder of the list. The opt flag should be manually handled to indicate that an empty arrayref is permitted.

Just realized we're sending out a separate BMASK for every ban. Defeats the purpose, huh?

When adding this, look at CAPAB EOPMOD, which is already enabled.

What's the point of including Evented::API::Engine manifests in git when the UPDATE command disregards them? Usually when there's a conflict, it's caused by one of the modules which is tied to the IRCd version at the time of last update.

One idea is to not allow any module versions to rely on IRCd version except for the core. The manifests for the ircd module and its submodules should be added to gitignore. The rest will use the auto-increment mechanism.

Fixing this would also give me an excuse to add charybdis +L support!

Users without +i should be omitted from NAMES when the issuer is not in the private or secret channel.

• Move PART logic to channel.pm rather than just in UserCommands.
• Make a second new method in user.pm for parting all channels (universal JOIN 0 handler)
• Make channel.pm JOIN 0 handler fire out a part_all
• Add outgoing part_all in JELP
• Add outgoing part_all in TS6
• Handle JOIN 0 in JELP
• Handle JOIN 0 in TS6

Currently mode definitions are only sent during burst. There is also no mode to remove modes once they're registered. Need to make AUM/ACM commands more dynamic with module loading and stuff. Also need a way to tell servers when modes are no longer available.

    It is now necessary for servers to track which of its own modes are familiar to
    other servers. This way, a server can determine if it needs to send out ADDUMODE,
    ADDCMODE, AUM, or ACM commands when new modes are added.

    Example: a new module was downloaded from the repository. The server configuration
    updated to include the mode provided by the new module. The server is rehashed.

    The server has tracked its own modes and is aware that NO servers are aware of the
    new mode, so it sends an ACM message to all servers. Mode-adding commands should
    be forwarded only if they occur outside of a burst.

it's called no_forward

It's currently an if/else chain which is strongly against my beliefs

I need to consider how I want to handle +qah/etc. forwarding to TS6 servers like charybdis which do not support these statuses.

We cannot assume that anyone with +q or +a or any mode higher than +o has +o in addition to whichever other statuses they have. Therefore it seems essential that a mode change of +q actually translates to +o. It must also be handled properly such that +qo does not translate to +oo and so on.

The question is whether it makes sense to do the opposite, i.e. to translate -o to -q—making ops on charybdis as powerful as owners on juno—or to instead immediately reverse the mode deop if done remotely by someone with a lower status. A third option would be to ignore +q and friends entirely on charybdis, which is the current behavior. The problem with doing that is that some channel actions require ops at a local level and may be ignored by charybdis.

I could also consider making it configure how you want this to behave:

1. Translate -o to -q
2. Reverse remote deops from servers without higher statuses
3. Ignore the existence of these modes altogether

Of course, all of this can be avoided by disabling juno's extra status modes.

Configuration::Set, Reload, and Git modules include calls to ->fire_command_data(), which was created back when only one linking protocol was supported. The result is that JELP-encoded commands are sent to servers that do not speak JELP. This method must be removed, and these modules need to use a normal ->fire_command().

Currently upgrading to the latest IRCd is a two-step process. This is far too complicated. Let's make a module that depends on Git and Reload and provides a unified UPGRADE command.

• make a ->convert_umode_string() like channels already have
• add MODE handler and outgoing command
• if MODE is received for a channel, propagate as TMODE. refer to ts6-protocol.txt

Both server protocols properly recognize when servers are marked as hidden, but they are still visible anyway to clients.

When adding and removing aliases from the configuration, the changes are not reflected until the Alias module is reloaded.

Evented::Database currently stores values semi-permanently if and only if they are updated during runtime to something other than what the legit ircd.conf says. I want the ircd.conf to be in sync with the configuration at all times. So E::D needs to generate a config in Evented::Configuration format in a certain pretty way which is defined by the E::D API. It needs to preserve comments as well.

Currently connect blocks and stuff have to have two IP entires, one for normal IPv4 and one for the IPv6 with embedded IPv4. It's hilarious. Net::IP has an ip_get_embedded_ipv4():

<mad> !eval Net::IP::ip_get_embedded_ipv4("0.0.0.0")
<mad> 0.0.0.0
<mad> !eval Net::IP::ip_get_embedded_ipv4("::FFFF:222.1.41.90")
<mad> 222.1.41.90
<mad> !eval Net::IP::ip_get_embedded_ipv4("0:0:0:0:0:FFFF:222.1.41.90")
<mad> 222.1.41.90

But Net::IP is not a core module; it would be an added dependency. I could probably implement this myself.

Kline/Dline/etc. are not yet implemented in TS6. The Ban::TS6 module exists and is loaded automatically whenever Ban and TS6 are both loaded.

I can not find a pattern among them. The users exist on the server but do not join the channel; they seem to be ignored from SJOIN. I checked to make sure all the users are being sent in SJOIN, and they are. They are seemingly ignored.

Modules with preserve_sym enabled will produce Perl warnings for every time a subroutine is redefined. Unfortunately no warnings 'redefine' cannot be applied because it is reset to normal state by the eval{}. Perhaps a workaround solution would be to temporarily disable all warning notices while reloading, but that could also result in a loss of useful debugging information.

Also, the oper which initiated the reload is sometimes notified that tons of modules have been upgraded to whatever the new IRCd version is. I think this is caused by a separate issue in the UPDATE command which causes disregard of JSON manifests.

• move local handling of away setting to user.pm
• update clients to use this
• update TS6 to use this
• update JELP to use this