1
0
Fork
You've already forked aqua-matrix-bot
0
No description
  • Python 97.6%
  • Dockerfile 1.6%
  • Shell 0.8%
Find a file
2023年04月26日 19:46:18 -07:00
bot fix: Update method to download media 2023年04月26日 19:46:18 -07:00
.gitignore Attempt to fix bot missing events 2022年04月12日 21:35:14 -07:00
build_and_install_libolm.sh feat: Added db and repost check 2021年04月30日 12:49:48 -07:00
docker-compose.yml Attempt to fix bot missing events 2022年04月12日 21:35:14 -07:00
Dockerfile fix: Update method to download media 2023年04月26日 19:46:18 -07:00
LICENSE Initial commit 2020年07月10日 11:46:48 -07:00
README.md Update README.md 2020年07月10日 11:55:59 -07:00
requirements.txt update requirements 2022年04月12日 23:38:54 -07:00
sample.config.yaml Initial commit 2020年07月10日 11:46:48 -07:00

Aqua Matrix Bot

This project is a WIP and is a rewrite of Aqua Telegram Bot.
This is a bot to count reactions to photos and videos. Aqua Matrix Bot is based on the template by anoadragon453 which is a template for matrix-nio. The documentation for matrix-nio can be found here.

About

This bot is a fun little karma system for Matrix groups. The bot reacts to any photo/video posted to the room with emojis which you can use to vote with. 👍 is 1 point, 👌 is 2 points, and ❤️ is 3 points.

Why is it called Aqua? Because this bot was originally thought to be pretty useless, just like the goddess from KonoSuba.

Requires Docker, Docker Compose, and Python 3. Python dependencies are managed by pip in requirements.txt
At the moment, Aqua supports up to 3 different Matrix rooms. This was a conscious design decision because I did not want my instance of the bot to be shared and used by unauthorized rooms.

Planned commands for Aqua include:

  • /karma: Shows the current number of points users in the group chat have
  • /repost_check: Checks to see if the photo has been posted in the last 30 days
  • /delete: Deletes the photo that /delete was used on
  • /source: Finds the source of an image/gif (currently only works with images drawn in the anime style)

Project structure

main.py

Initialises the config file, the bot store, and nio's AsyncClient (which is used to retrieve and send events to a matrix homeserver). It also registering some callbacks on the AsyncClient to tell it to call some functions when certain events are received (such as an invite to a room, or a new message in a room the bot is in).

It also starts the sync loop. Matrix clients "sync" with a homeserver, by asking constantly asking for new events. Each time they do, the client gets a sync token (stored in the next_batch field of the sync response). If the client provides this token the next time it syncs (using the since parameter on the AsyncClient.sync method), the homeserver will only return new event since those specified by the given token.

This token is saved and provided again automatically by using the client.sync_forever(...) method.

config.py

This file reads a config file at a given path (hardcoded as config.yaml in main.py), processes everything in it and makes the values available to the rest of the bot's code so it knows what to do. Most of the options in the given config file have default values, so things will continue to work even if an option is left out of the config file. Obviously there are some config values that are required though, like the homeserver URL, username, access token etc. Otherwise the bot can't function.

storage.py

Creates (if necessary) and connects to a SQLite3 database and provides commands to put or retrieve data from it. Table definitions should be specified in _initial_setup, and any necessary migrations should be put in _run_migrations. There's currently no defined method for how migrations should work though.

callbacks.py

Holds callback methods which get run when the bot get a certain type of event from the homserver during sync. The type and name of the method to be called are specified in main.py. Currently there are two defined methods, one that gets called when a message is sent in a room the bot is in, and another that runs when the bot receives an invite to the room.

The message callback function, message, checks if the message was for the bot, and whether it was a command. If both of those are true, the bot will process that command.

The invite callback function, invite, processes the invite event and attempts to join the room. This way, the bot will auto-join any room it is invited to.

bot_commands.py

Where all the bot's commands are defined. New commands should be defined in process with an associated private method. echo and help commands are provided by default.

A Command object is created when a message comes in that's recognised as a command from a user directed at the bot (either through the specified command prefix (defined by the bot's config file), or through a private message directly to the bot. The process command is then called for the bot to act on that command.

message_responses.py

Where responses to messages that are posted in a room (but not necessarily directed at the bot) are specified. callbacks.py will listen for messages in rooms the bot is in, and upon receiving one will create a new Message object (which contains the message text, amongst other things) and calls process() on it, which can send a message to the room as it sees fit.

A good example of this would be a Github bot that listens for people mentioning issue numbers in chat (e.g. "We should fix #123"), and the bot sending messages to the room immediately afterwards with the issue name and link.

chat_functions.py

A separate file to hold helper methods related to messaging. Mostly just for organisational purposes. Currently just holds send_text_to_room, a helper method for sending formatted messages to a room.

errors.py

Custom error types for the bot. Currently there's only one special type that's defined for when a error is found while the config file is being processed.

sample.config.yaml

The sample configuration file. People running your bot should be advised to copy this file to config.yaml, then edit it according to their needs. Be sure never to check the edited config.yaml into source control since it'll likely contain sensitive details like passwords!

Questions?

Any questions? Ask in #nio-template:amorgan.xyz!