Create external module repository at the znc organisation for gathering external modules and permitting easier installation of them. #437

New Issue

2026-10-05T04:20:46+02:00

adam commented

2026-10-05 04:20:46 +02:00

You can make a new repository within the organisation for external modules that can be installed using some sort of simple shell script. This allows for easier calling of "let's make this module external" whilst not directly inconveniencing other people because installing them. This could be as easy as znc-module {install|uninstall|update} sample.cpp, or even providing a module within znc to list all available installable modules.

Currently external modules are to be found by the people who host their znc instance and are listed on the Wiki - but if this was in its own repository, it would be easier and vastly more secure to install external modules if those who maintain the znc repository and are familiar with how znc functions, that know what kind of exploits to look for,

As long as clearly denoted that the znc team does not maintain or is responsible for issues caused by external modules in the repository I do not see it being an issue to make the installation of said external modules easier.

These types of systems are implemented and work well for weechat (https://github.com/weechat/scripts) and irssi (https://github.com/irssi/scripts.irssi.org) - I think ZNC would benefit from adapting this system as well.

This idea is absolutely not fully fleshed out, and probably needs a bit more thought to it. There's a few things brought up from irc that are worth keeping in mind:

Should this be a module that will install these scripts for you (integrated with ListAvailMods, LoadMod), or a shell script?
Automatic updating?
How strict do you want to be with maintaining it?
Should znc ship with only the core required modules, and have most of the rarely used modules be in the znc-modules repository. Such as #786, awaynick.cpp, sample.cpp, stickychan.cpp, notes.cpp and so on.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7193402-create-external-module-repository-at-the-znc-organisation-for-gathering-external-modules-and-permitting-easier-installation-of-them?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

You can make a new repository within the organisation for external modules that can be installed using some sort of simple shell script. This allows for easier calling of "let's make this module external" whilst not directly inconveniencing other people because installing them. This could be as easy as `znc-module {install|uninstall|update} sample.cpp`, or even providing a module within znc to list all available installable modules. Currently external modules are to be found by the people who host their znc instance and are listed on the [Wiki](http://wiki.znc.in/Category:External_Modules) - but if this was in its own repository, it would be easier and vastly more secure to install external modules if those who maintain the znc repository and are familiar with how znc functions, that know what kind of exploits to look for, As long as clearly denoted that the znc team does not maintain or is responsible for issues caused by external modules in the repository I do not see it being an issue to make the installation of said external modules easier. These types of systems are implemented and work well for weechat (https://github.com/weechat/scripts) and irssi (https://github.com/irssi/scripts.irssi.org) - I think ZNC would benefit from adapting this system as well. This idea is absolutely not fully fleshed out, and probably needs a bit more thought to it. There's a few things brought up from irc that are worth keeping in mind: - Should this be a module that will install these scripts for you (integrated with ListAvailMods, LoadMod), or a shell script? - Automatic updating? - How strict do you want to be with maintaining it? - Should znc ship with only the core required modules, and have most of the rarely used modules be in the `znc-modules` repository. Such as #786, `awaynick.cpp`, `sample.cpp`, `stickychan.cpp`, `notes.cpp` and so on. ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7193402-create-external-module-repository-at-the-znc-organisation-for-gathering-external-modules-and-permitting-easier-installation-of-them?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:20:47 +02:00

Also it somehow should support C++/perl/python modules.

Also it somehow should support C++/perl/python modules.

adam commented

2026-10-05 04:20:48 +02:00

Create subdirectories to them?

Create subdirectories to them?

adam commented

2026-10-05 04:20:49 +02:00

Some modules also have data files, e.g. templates for web

Some modules also have data files, e.g. templates for web

adam commented

2026-10-05 04:20:49 +02:00

More subdirectories?

<language>/<module>/<whatever_module_wants>?

Or even <language>/<author>/<module>/<whatever_module_wants> or <author>/<language>/<module>/<whatever_module_wants>?

More subdirectories? `<language>/<module>/<whatever_module_wants>`? Or even `<language>/<author>/<module>/<whatever_module_wants>` or `<author>/<language>/<module>/<whatever_module_wants>`?

adam commented

2026-10-05 04:20:50 +02:00

@Mikaela there's no problem with subdirectories :)

Just I mentioned it here, because while implementing this feature, need not to forget about such cases.

@Mikaela there's no problem with subdirectories :) Just I mentioned it here, because while implementing this feature, need not to forget about such cases.

adam commented

2026-10-05 04:20:51 +02:00

The repo could contain simple manifest files that describe where to get each module and how to install it (for the script).

eg. znc-modules/1.4/push.json:

{
    "name": "push",
    "description": "Push notification service module for ZNC",
    "source": "https://raw.githubusercontent.com/jreese/znc-push/ff4518c/push.cpp",
    "data": "...",
    "author": "John Reese",
    ...
}

The repo could contain simple manifest files that describe where to get each module and how to install it (for the script). eg. znc-modules/1.4/push.json: ``` { "name": "push", "description": "Push notification service module for ZNC", "source": "https://raw.githubusercontent.com/jreese/znc-push/ff4518c/push.cpp", "data": "...", "author": "John Reese", ... } ```

adam commented

2026-10-05 04:20:51 +02:00

InspIRCd handles it's extra modules in a similar fashion: https://github.com/inspircd/inspircd-extras
which is being loaded on demand trough this script: https://github.com/inspircd/inspircd/blob/master/modulemanager

InspIRCd handles it's extra modules in a similar fashion: https://github.com/inspircd/inspircd-extras which is being loaded on demand trough this script: https://github.com/inspircd/inspircd/blob/master/modulemanager

adam commented

2026-10-05 04:20:52 +02:00

In ZNC 1.7 modules can also contain a number of .po files

In ZNC 1.7 modules can also contain a number of `.po` files

adam commented

2026-10-05 04:20:53 +02:00

What about also requiring integration tests?

What about also requiring integration tests?

adam commented

2026-10-05 04:20:53 +02:00

What about also requiring integration tests?

that would be good, but we don't have an easy way to do that yet. The integration tests which are inside ZNC repo work for ZNC itself. To somehow reuse the framework for external modules, need to make it usable as a library, or in some other way

> What about also requiring integration tests? that would be good, but we don't have an easy way to do that yet. The integration tests which are inside ZNC repo work for ZNC itself. To somehow reuse the framework for external modules, need to make it usable as a library, or in some other way

adam commented

2026-10-05 04:20:54 +02:00

Working proof of concept: https://github.com/RealKindOne/znc-external

Working proof of concept: https://github.com/RealKindOne/znc-external

adam commented

2026-10-05 04:20:55 +02:00

to clarify, this is PoC not of the repository, but how a module can use integration test framework outside of ZNC's source

to clarify, this is PoC not of the repository, but how a module can use integration test framework outside of ZNC's source

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#437