Repository navigation
Centralization of all existing 3rd party plugins #1
Description
The main idea behind this is to centralize all plugins and make this repository the official distribution of plugins.
There are some major advantages to this, such as:
- Being able to update unmaintained plugins whose authors have left Aliucord
- Security; random plugin authors will be unable to silently distribute malware unlike now
- Allow for breaking changes to Aliucord core, as we would be able to rapidly test and update all affected plugins
- Maintain a base level of code quality
Existing distribution
This does not mean that distributing plugins outside of this repository will become impossible, but that this will become the primary method
to publishing new plugins. As for what it means for the existing distribution methods:
- The existing plugin channels
#new-pluginsand#plugins-listwill be archived - A new plugin channel
#unofficial-pluginscan be created for the listing of low-quality or meme plugins (ie,/minky, PetPet, etc) to be used with the builtin PluginDownloader. - The current global plugin repository will be repurposed as an unofficial plugins repository
- The PluginWeb/PluginRepo can still list these plugins under a specific "unofficial" tab or something similar
- Either
PluginWeborPluginRepowill eventually be turned into a coreplugin, becoming the de-facto way to install Aliucord plugins. (this was a long time coming)
Codeowners
The original authors of plugins should still be able to exert some level of control over their own plugins. Random contributors should still be approved by the original (or currently maintaining) author to ensure that the changes conform to the vision they hold for their own plugins.
As such, we can implement CODEOWNERS control for each plugin to require PR approval to any changes involving the source code for their plugins.
A trusted global plugin maintainer can then additionally review the changes to ensure that no malicious code has been introduced; ignoring the code quality itself in most cases (unless it's egregious), and then merge the changes. This ensure that untrusted plugin developers don't have the ability to silently merge malicious code.
This is still highly up for debate.
Project structure
I plan on following the same structure as the current plugins template, with this being a huge monorepo holding a bunch of isolated Gradle modules under ./plugins/. We currently have around ~280 plugins I believe, and since most of them will be using the same set of dependencies, this shouldn't cause any significant performance issues with syncing. Since Aliucord Gradle Plugin v2 supports configuration caching, this will be even less of an issue.
Migration procedure
- This repository is prepared for migration
- Make a publicly editable spreadsheet of every single plugin
- Allow willing plugin devs/contributors to mark themselves as claiming to migrate a plugin
- Withhold making improvements to plugins, centralizing everything first is more important.
- Plugin is PR'd to central repo, reviewed and approved by a maintainer
- Assign yourself as a codeowner if it is one of your own plugins
- Plugin is marked done in spreadsheet, move on to next one.
Questions
- Licensing? I would prefer to license this entire repository under GPLv3, but what if the original plugin authors did not license their plugins? Should we go track them down to ask for permission?
- Who would be codeowner for unmaintained plugins?
- Who is trustworthy enough to allow direct merge/write perms this repository?
Activity
Ushie commentedon Feb 7, 2026
Whats the motivation behind this?
I believe with the existence of an official repository, aliucord should have no interest housing any unofficial sources within it's community, either plugin guidelines get written dedicated what would typically be accepted into the repository and outright not house anything that fits said requirement or we house these low-quality/meme plugins regardless of their uselessness just for the sake of user experience and safety
Guidelines for codeownership needs heavy discussion, just because you authored said plugin doesn't automatically mean that you are trusted enough to have write access to it in the centralized repository where a trust factor is perceived by the user
Since a majority of the plugins will likely end up being refactored to Kotlin and have significant code quality improvements, is this necessary? Should be looked into, besides this question might simply be answered by looking into the repositories first and seeing if there are such unlicensed/restrictively licensed plugins to begin with, I have a local clone of every single plugin repo so I should be able to check in my next session
I believe this is a simple question, the aliucord maintainers by default followed by high trust individuals within the communities, for example individuals like @mantikafasi and @zt64, many more will come to mind and I'm sure you already have atleast a dozen people you trust, what matters most here is trust afterall and who can you trust more than the friends who were as involved in this project as you were for years past and years to come
rushiiMachine commentedon Feb 7, 2026
I see it as the most sensible way to setup this up. If you're talking about separating each plugin out to an individual repository under a separate org, that reintroduces a lot of the same issues as decentralized plugins, with maintaining becoming significantly more difficult for no benefit.
Well what about Vencord's
#unofficial-plugins? I would rather there be some sort of listing housing low quality plugins rather than them being distributed p2p with absolutely no initial verification at all.I agree that we need plugin rules/guidelines though.
Authorship won't mean that you will have direct write access, it will still need to be approved by a trusted maintainer.
Refactored plugins still require that the original license be preserved especially if its copyleft. But perhaps this is less of an issue than I thought, and we can deal with it on a case-by-case basis.
rushiiMachine commentedon Feb 7, 2026
Currently, who I have in mind for reviewing is:
There's probably someone I'm forgetting
If some legacy contributors come back they could be added as well.
rushiiMachine commentedon Feb 7, 2026
Additionally, core can forcefully update plugins to their centralized variant based on name (or aliases) once this is completed.
Ushie commentedon Feb 7, 2026
I mean, why a mono repo? I don't want an individual repo per plugin ofcourse, but I don't get the point of a mono repo, is that to avoid using the same AGP/gradle/kotlin versions? isn't part of the central repo migration going to be migrating things to work on the same version?
The point isn't about housing them, the point is about not having Aliucord be in a state where such thing is necessary, if the guidelines are done correctly then hopefully there will not be any need for any unofficial plugin discovery, as genuine plugins would just get added to central repo, the only plugins that would have no chance would be improper ones that are creepy and-or self-botty
What I meant that, it's pointless to talk about this if we don't have any repositories that aren't permissive, we better check first before continuing the topic on this, i think it's unlikely, did Aliucord always have a plugin template?
rushiiMachine commentedon Feb 7, 2026
wdym, everything is supposed to be tied to the same version, that's why its a monorepo with all the plugins
Okay well let's sort out the guidelines first (#2) before continuing discussion on unofficial plugins then.
The plugin template has existed ever since the original gradle plugin was released I believe, but it never had a license attatched to it (still doesn't).