Matrix-Mirrors/mjolnir
1
0
Fork 0
mirror of https://github.com/matrix-org/mjolnir.git synced 2024-10-01 01:36:06 -04:00
Code Issues Packages Projects Releases Wiki Activity
gnuxie/commands
mjolnir/package.json

66 lines
2.6 KiB
JSON
Raw Permalink Normal View History

Absolute bare minimum for a bot
2019-09-25 22:13:20 -04:00
{
"name": "mjolnir",
v1.6.1
2022-11-23 05:56:46 -05:00
"version": "1.6.1",
Absolute bare minimum for a bot
2019-09-25 22:13:20 -04:00
"description": "A moderation tool for Matrix",
"main": "lib/index.js",
"repository": "git@github.com:matrix-org/mjolnir.git",
"author": "The Matrix.org Foundation C.I.C.",
"license": "Apache-2.0",
"private": true,
"scripts": {
"build": "tsc",
Fix the test script `yarn test:manual` and add it to tsconfig (#234) * Add test:manual launch script to tsconfig this is so we won't keep breaking it
2022-02-24 09:46:15 -05:00
"postbuild": "rm -rf lib/test/ && cp -r lib/src/* lib/ && rm -rf lib/src/",
Make the [un]ban command smarter Fixes https://github.com/matrix-org/mjolnir/issues/11
2019-11-13 23:38:19 -05:00
"lint": "tslint --project ./tsconfig.json -t stylish",
Let's make sure that we can still check for errors with concise error handling
2022-01-06 06:19:19 -05:00
"start:dev": "yarn build && node --async-stack-traces lib/index.js",
make yarn test only runs unit tests for now while we sortout CI setup
2021-09-27 07:38:43 -04:00
"test": "ts-mocha --project ./tsconfig.json test/commands/**/*.ts",
Remove debug leftovers from a test. (#314) * Remove debug leftovers from a test. This is really terrible and has meant whenever anyone has run `yarn test:integration` they have only been running this test. 💀💀💀 https://www.youtube.com/watch?v=jmX-tzSOFE0 * Set a default timeout for integration tests that is 5 minutes long. Seriously, I don't think there is much to gain by making people guess a reasnoble time for a test to complete in all the time, especially with how much Synapse changes in response time and all of the machines involved in running these tests. * Warn when giving up on being throttled * For some reason it takes longer for events to appear in /state no i am not going to track down why yet. * Rate limiting got a lot more aggresive. https://github.com/matrix-org/synapse/pull/13018 Rate limiting in Synapse used to reset the burst count and remove the backoff when you were spamming continuously, now it doesn't. Ideally we'd rewrite the rate limiting logic to back off for longer than suggested so we could get burst again, but for now lets just unblock CI by reducing the number of events we send in these tests.
2022-07-06 09:20:25 -04:00
"test:integration": "NODE_ENV=harness ts-mocha --async-stack-traces --require test/integration/fixtures.ts --timeout 300000 --project ./tsconfig.json \"test/integration/**/*Test.ts\"",
Update CONTRIBUTING.md to show how to debug mjolnir. (#433)
2022-11-23 05:55:00 -05:00
"test:integration:single": "NODE_ENV=harness npx ts-mocha --require test/integration/fixtures.ts --timeout 300000 --project ./tsconfig.json",
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 13:03:06 -05:00
"test:appservice:integration": "NODE_ENV=harness ts-mocha --async-stack-traces --timeout 300000 --project ./tsconfig.json \"test/appservice/integration/**/*Test.ts\"",
Update CONTRIBUTING.md to show how to debug mjolnir. (#433)
2022-11-23 05:55:00 -05:00
"test:appservice:integration:single": "NODE_ENV=harness npx ts-mocha --timeout 300000 --project ./tsconfig.json",
Change antispam Python module verison with mjolnir version. (#264) The reason we want this is so that people do not forget to change the version number in the synapse module. The precedent is that the version number has been 0.1.0 since the begging until now. While this solution does mean that there may be new version of the module where nothing has actually changed, this is still better than not changing the version at all. Another version scheme for the module would be inconsistent to the git repository tags and that has the potential to cause much more confusion than "blank" version bumps. If this is a problem, then antispam must be extracted to another repository. In order to test this, run `yarn version --patch` observe the changes with `git log` and `git diff HEAD~`, then YOU MUST delete the tag with `git tag --delete vd.d.d` when you are finished. * more robust
2022-04-12 11:36:35 -04:00
"test:manual": "NODE_ENV=harness ts-node test/integration/manualLaunchScript.ts",
"version": "sed -i '/# version automated/s/[0-9][0-9]*\\.[0-9][0-9]*\\.[0-9][0-9]*/'$npm_package_version'/' synapse_antispam/setup.py && git add synapse_antispam/setup.py && cat synapse_antispam/setup.py"
Absolute bare minimum for a bot
2019-09-25 22:13:20 -04:00
},
"devDependencies": {
Config fixes (#432) * Use the npm package `config` to load the config. This is what was used prior to https://github.com/matrix-org/mjolnir/pull/347. It was a nice idea motivated to drop a dependency that was confusing. It was just never followed through and was underestimated how much disruption it would cause. It was also believed that the library would mean there could only ever be one global copy of the config, It was followed up by: https://github.com/matrix-org/mjolnir/pull/369 https://github.com/matrix-org/mjolnir/pull/357 https://github.com/matrix-org/mjolnir/pull/429 https://github.com/matrix-org/mjolnir/pull/397/files https://github.com/matrix-org/mjolnir/issues/365 For simplicity sake I am reinstating the library. The practice of loading default.yaml by default is also dangerous and has led to issues multiple times in #mjolnir:matrix.org. It is a sample and not a default. In a following commit I will be adding the ability to specify the config to use from the cli. * Allow config to be specified with an explicit cli argument. * Update doc to transition away from old config handling
2022-11-23 05:55:22 -05:00
"@types/config": "^3.3.0",
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
"@types/crypto-js": "^4.0.2",
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 13:03:06 -05:00
"@types/express": "^4.17.13",
enable noImplicitAny (#209)
2022-02-02 07:43:05 -05:00
"@types/html-to-text": "^8.0.1",
New command `!mjolnir since <date or duration> <kick | ban | show> <limit> [reason] [...rooms]` (#238) A new command `since` to affect all users who have joined a protected room since a given date.
2022-03-21 05:39:15 -04:00
"@types/humanize-duration": "^3.27.1",
load config yaml manually, remove more references to static config (#347)
2022-08-16 10:51:18 -04:00
"@types/js-yaml": "^4.0.5",
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"@types/jsdom": "^16.2.11",
Replace shutdown_room API with DELETE /_synapse/admin/v1/rooms/<room_id> - Resolves #76, closes #96 As per https://github.com/matrix-org/synapse/issues/9052, shutdown_room is going away, to be replaced with DELETE /_synapse/admin/v1/rooms/<room_id>.
2021-07-28 04:56:50 -04:00
"@types/mocha": "^9.0.0",
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 13:03:06 -05:00
"@types/nedb": "^1.8.12",
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
"@types/node": "^16.7.10",
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 13:03:06 -05:00
"@types/pg": "^8.6.5",
"@types/request": "^2.48.8",
New command `!mjolnir since <date or duration> <kick | ban | show> <limit> [reason] [...rooms]` (#238) A new command `since` to affect all users who have joined a protected room since a given date.
2022-03-21 05:39:15 -04:00
"@types/shell-quote": "1.7.1",
Update package.json and yarn.lock to include harness dependencies.
2021-09-09 11:40:12 -04:00
"crypto-js": "^4.1.1",
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"eslint": "^7.32",
Update packages
2021-07-01 15:45:28 -04:00
"expect": "^27.0.6",
"mocha": "^9.0.1",
fix CI (#282) ts-mocha has also been updated to make running locally possible (else it gives a confusing error that tsconfig.json is not "json" or the likes)
2022-05-03 06:20:40 -04:00
"ts-mocha": "^9.0.2",
Update packages
2021-07-01 15:45:28 -04:00
"tslint": "^6.1.3",
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 13:03:06 -05:00
"typescript": "^4.8.4",
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"typescript-formatter": "^7.2"
Absolute bare minimum for a bot
2019-09-25 22:13:20 -04:00
},
"dependencies": {
Factor out protected rooms config management from Mjolnir. The combination of `resyncJoinedRooms`, `unprotectedWatchedListRooms`, `explicitlyProtectedRoomIds`, `protectedJoinedRoomIds` was incomprehensible. https://github.com/matrix-org/mjolnir/issues/370 Separating out the management of `explicitlyProtectedRoomIds`, then making sure all policy lists have to be explicitly protected (in either setting of `config.protectAllJoinedRooms`) will make this code much much simpler. We will later change the `status` command to explicitly show which lists are watched and which are watched and protected.
2022-10-13 12:19:32 -04:00
"await-lock": "^2.2.2",
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 13:03:06 -05:00
"body-parser": "^1.20.1",
Config fixes (#432) * Use the npm package `config` to load the config. This is what was used prior to https://github.com/matrix-org/mjolnir/pull/347. It was a nice idea motivated to drop a dependency that was confusing. It was just never followed through and was underestimated how much disruption it would cause. It was also believed that the library would mean there could only ever be one global copy of the config, It was followed up by: https://github.com/matrix-org/mjolnir/pull/369 https://github.com/matrix-org/mjolnir/pull/357 https://github.com/matrix-org/mjolnir/pull/429 https://github.com/matrix-org/mjolnir/pull/397/files https://github.com/matrix-org/mjolnir/issues/365 For simplicity sake I am reinstating the library. The practice of loading default.yaml by default is also dangerous and has led to issues multiple times in #mjolnir:matrix.org. It is a sample and not a default. In a following commit I will be adding the ability to specify the config to use from the cli. * Allow config to be specified with an explicit cli argument. * Update doc to transition away from old config handling
2022-11-23 05:55:22 -05:00
"config": "^3.3.8",
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"express": "^4.17",
Give the ability to moderators to react quickly to /report abuse reports. (#137)
2021-11-09 07:15:49 -05:00
"html-to-text": "^8.0.0",
New command `!mjolnir since <date or duration> <kick | ban | show> <limit> [reason] [...rooms]` (#238) A new command `since` to affect all users who have joined a protected room since a given date.
2022-03-21 05:39:15 -04:00
"humanize-duration": "^3.27.1",
A command to show when users in a given room have joined (#225)
2022-03-07 05:34:25 -05:00
"humanize-duration-ts": "^2.1.1",
Update packages
2021-07-01 15:45:28 -04:00
"js-yaml": "^4.1.0",
Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38 (#135) * Intercept /report and display human-readable abuse reports in the moderation room - Resolves #38
2021-10-07 08:42:08 -04:00
"jsdom": "^16.6.0",
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 13:03:06 -05:00
"matrix-appservice-bridge": "^5.0.0",
New command `!mjolnir since <date or duration> <kick | ban | show> <limit> [reason] [...rooms]` (#238) A new command `since` to affect all users who have joined a protected room since a given date.
2022-03-21 05:39:15 -04:00
"parse-duration": "^1.0.2",
manymjolnir appservice (#364) Mjolnir can now be run as an application service, meaning it will host multiple independent mjolnirs that can be requested by users. If the user is on the same homeserver as the appservice is deployed on, then they can provision a mjolnir via a widget https://github.com/matrix-org/mjolnir-widget. Otherwise they can invite the appservice bot to a room they want to protect. This will create them a mjolnir, a management room and a policy list. The appservice shares the same docker image as the bot, but is started slightly differently by specifying "appservice" as the first argument to docker run (this s managed by `mjolnir-entrypoint.sh`. We could have used another Dockerfile for the appservice, extending the existing one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. A list of followup issues can be found here https://github.com/issues?q=is%3Aopen+is%3Aissue+author%3AGnuxie+archived%3Afalse+label%3AA-Appservice. Somewhat relevant and squashed commit messages(regrettably squashing because frankly these won't make sense in isolation): * draft widget backend * add `managementRoomId` to `provisionNewMjolnir` * remove ratelimits from appservice mjolnirs * add /join endpoint to api backend * tighter guard around room type in PolicyList matrix-bot-sdk imporved the types for this * enable esModuleInterop * launch and use postgres in a container whilst using mx-tester * limited access control policy list used for access control * Redesign initialization API of many mjolnir. It's much harder to forget to initialize the components now that you have to in order to construct them in the first place. * Ammend config not to clash with existing CI this means that the appsrvice bot is now called 'mjolnir-bot' by default which was easier than going through old code base and renaming * Change entrypoint in Dockerfile so that we can start the appservice. We could have used another Dockerfile for the appservice, extending the exising one but we decided not to because there would have been lots of fiddling around the entrypoint and logistics involved around adding a tag for it via github actions. Not to mention that this would be duplicating the image just to run it with a different binary. This solution is much simpler, backwards compatible, and conscious about the future. Co-authored-by: gnuxie <gnuxie@element.io>
2022-11-15 13:03:06 -05:00
"pg": "^8.8.0",
load config yaml manually, remove more references to static config (#347)
2022-08-16 10:51:18 -04:00
"shell-quote": "^1.7.3",
"yaml": "^2.1.1"
Bump minimum node version to >=14 Needed to merge https://github.com/matrix-org/mjolnir/pull/186 & node 12 is approaching EOL.
2022-01-18 11:33:30 -05:00
},
"engines": {
Bump minimum node version to 16. (#316) * Bump minimum node version to 16. We already made the mistake of using features from 16 without realising Previously: https://github.com/matrix-org/mjolnir/pull/192 * Make sure CI uses specific version of node and we also lint. https://github.com/matrix-org/pipelines/blob/master/mjolnir/pipeline.yml#L13
2022-07-06 09:50:33 -04:00
"node": ">=16.0.0"
Absolute bare minimum for a bot
2019-09-25 22:13:20 -04:00
}
}
Reference in New Issue Copy Permalink