Bofh
8d31090324
|
||
|---|---|---|
| api/v1 | ||
| classes | ||
| config | ||
| css | ||
| fonts/forkawesome | ||
| img | ||
| js | ||
| views | ||
| .gitignore | ||
| LICENSE | ||
| README.md | ||
| base.php | ||
| cli.php | ||
| cron.php | ||
| index.php | ||
| login.php | ||
README.md
Apub-ctpanel
ActivityPub-based software Control Panel for: controlling bad actors, watching new users activity (until you build up trust, then whitelist it), filter posts (federated, unlisted, followers-only and DM (for example, for spamming via DM)), filter on user, automations on configured filters (auto suspend/silence/report users, auto delete posts, manual reporting and management of positives)...
In short: manage your ActivityPub implementation software (ex: Mastodon) in a next level way.
Installation
The project is a web application, therefore it uses only these 4 languages: PHP, HTML, CSS, JS.
First steps
First of all, read this basic guideline of requirements:
- You need any standalone web server with any PHP version you can/want (also see the "Package requirements" below).
- Make sure the web server has access to your Mastodon/Pixelfed (or whatever): web (via HTTP), database (via IP:PORT), redis (via IP:PORT)... (the needed services to be accessed, depends on the instance managed and configured in the web interface).
- No need for any database for saving this web application's data: instance configuration, manager users, jobs... It is saved in common files.
- Copy config/application.php.example to config/application.php and modify it to your needs.
- For background jobs, you only need to run the cron.php script with php cron.php or php /your/deployed/path/cron.php in any way you want. Also the interval to run this job can be anyone you want (1 minute, 5 minutes or even more...). (The recommended setting is to run every minute).
Package requirements
This requirements are specified with their common names, adapt the package names to your needs (version, operating system...):
- php-pqsql (Postgres)
- php-curl (Curl)
About Versioning
All tags are created from a moment of the "main" branch. There can be alpha- or beta- prefixes to a version, but all prefixes have there own numeration.
Version numeration is representad as this examples: v1.2.0, alpha-v1.0.0, beta-v3.0.2. In this example v1.2.0 is higher than any alpha- or beta- numeration, as this prefixes are only used as a state of development of this web application.
Updates
Just do a git pull and git checkout THEVERSION
Contributing
You can send patches, code in any format you want, or suggestions to the email bofh@nogafam.es