[Proposal] Module folder organization & 'default' modules.conf #391

Shawn-Smith opened this Issue Dec 24, 2012 · 7 comments


None yet

5 participants


Personally, I think it would appear 'neater' if the modules folder had some sort of organizational structure to it.


  • m_md5
  • m_sha256
  • m_ripemd160

~/ssl ( These two modules could be renamed from m_ssl* to m_ )

  • m_ssl_gnutls
  • m_ssl_openssl


  • m_services_account
  • m_servprotect

~/deprecated ( Any module that will likely be removed in the next version should be moved to this folder )

  • m_halfop
  • m_chanprotect

As for the 'default' modules.conf, it would be nice if we could cut down on the size of modules.conf and make it easier for an end-user to read through. I think that some of the lesser-used modules should be split off into a modules-extra.conf that a user can include if they wish.

Some modules that I think would be good to move to the modules-extra.conf:

  • m_allowinvite
  • m_autoop
  • m_banredirect
  • m_blockamsg
  • m_blockcaps
  • m_cban
  • m_chancreate
  • m_commonchans
  • m_conn_join
  • m_customtitle
  • m_cycle
  • m_dccallow
  • m_delayjoin
  • m_delaymsg
  • m_jumpserver
  • m_kicknorejoin
  • m_maphide
  • m_namedmodes
  • m_nationalchars
  • m_nopartmsg
  • m_ojoin
  • m_operlevels
  • m_passforward

There are more but I got lazy and didn't want to continue through the list. Anyway, you get the idea, remove all the modules that aren't used very often and put them into their own config so that the average joe trying to setup a server doesn't have to read through a 4 hour config.


Unflattening the module hierarchy was one of the things proposed on IRC for -next. However, it would break linking like crazy (replacing the module names for linking against older versions would be a nightmare) so it's probably better to delay until 3.0 rather than 2.2.

Moving certain modules to an extra configuration file seems pointless. Everyone has their different 10% of the modules that they use. What might be nice however is a set of stripped configuration files which are easy to configure for people who know what they are doing.


Then just do the folder organization for now, renaming the actual module isn't a big deal. I only pointed out that they could be renamed in the case of m_ssl_gnutls and m_ssl_openssl because it seems a bit odd to have them in an SSL folder and also have ssl in their name


It'd be good if you could configure what modules of the Crypto folder would be used then in all modules. m_cloaking hardcoding "hash/md5" makes little sense. If these modules would be fully interchangeable, that'd make it less confusing, imho.


m_cloaking hardcoding "hash/md5" makes little sense.

Thats not hardcoded really. It's requiring a hashing module which provides the MD5 algorithm. This could be provided by a module of any name.

inspircd member

maybe we could get rid of the m_ prefix as well when we do this

regarding the deprecated modules, they will be removed in 2.2


Whats the exact benefit of the directory organization except that it looks neater? In my opinion is it useless for most people since they never will look at the modules after installation (or even before, for that matter), they just want them to be compiled and working. Most wouldn't want to go through some tree of directories to see if the modules is placed in a directory that may make sence for the developers, but not for one who is just setting up InspIRCd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment