Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Expose some homeserver functionality to spam checkers #6259
I've tried to avoid passing homeserver object to the modules, as it basically ends up forcing us to keep the entire Synapse API stable so as to not break installed modules. Generally we've tried to document the interface of the objects we're passing in, e.g. for password providers we pass in
The linters broke, should be fixed by merging in develop.
As per #synapse-dev:matrix.org, we've tried hard to avoid giving the homeserver object to pluggable modules, as otherwise its impossible to know what interfaces modules depend on. This adds a maintenance burden to synapse devs (makes it harder to know what functionality is relied on by third party modules), third party module devs (they don't know what APIs are stable or when they might just break) and server admins (don't know whether a new version of synapse will break their modules or not without testing, possibly causing service outages).
The flip side to this is that its more annoying to develop modules that use functionality that is not currently exposed by Synapse, as it means opening a PR on Synapse and waiting for that to be merged and released.
However given the fact that modules hook into core parts of Synapse and are security sensitive (e.g. auth providers), we think that the need for stability outweighs the need to be able to quickly add new features.
As such the solution we've adopted is to pass in a well-defined ModuleApi interface to modules, and I'd suggest you use that and adding any necessary extra functionality. (Other potential solutions exist, including adding version constraints, but none of those have been implemented or thought through.)