thecodingden / highlights Goto Github PK

Highlights should use tracing and Jaeger to allow for better observability and in-depth logging.

Replace the current system with the following:

• Using @Highlights add moon would add a keyword for the entire current server
• Using @Highlights add "moon" in #bots would add a keyword specific to the bots channel
• Using @Highlights mute #bots would make server-wide keywords ignore the bots channel

Hey @ThatsNoMoon, feel free to submit a PR to showcase your project!

• SeaQL/sea-orm#403

Right now, if highlights is missing any permissions it needs, it'll just fail on any command usage.

It should check if it has SEND_MESSAGES before doing any command handling. If it doesn't, but it does have ADD_REACTIONS, then it should add a reaction, probably 🔇. Otherwise, it should just do nothing and return.

It should check if it has EMBED_LINKS before running a command that needs embeds, right now just help or about. If it doesn't, it should send a sad message about its beautiful embeds that you can't see. That should be easy to do with a macro.

Example use-case: highlighting possibly problematic words for moderation purposes

The current DB abstraction is pretty leaky. It leaks the fact that IDs are stored as i64s, which causes a lot of conversion between i64 and UserId, and some conversion to u64.

This could probably be solved by making the fields private and using getters that convert to UserId/u64 and a similar converting constructor.

Another option is storing the IDs as serenity models and converting in the database interaction methods. This might cause less friction with the rest of the API.

Internal functions, structs, modules ect. should have inline documentation.

The invite link on your github page is
https://discord.com/api/oauth2/authorize?client_id=740802975576096829&scope=bot

it adds the bot but the bot won't show up for slash commands.

I got help getting a link that fixed the scope in the support server you have linked, so I'm good! But it will probably help future people.

also idk if you know but carlbot just disabled its highlight feature for anyone without manage messages permissions.
so people are going to be looking for alternatives again. that's how I found you.

Mobile devices like to capitalize stuff automatically, and About doesn't do anything. Expected behavior: it should be same as about.

Add an environment variable for private bots so highlights doesn't generate an invite link in the about command.

Mentioning the bot should not be necessary when DMing it.

Discord gives out 500 errors weirdly often and it seems like retrying would be prudent.

Will probably need to figure out if the keyword is inside a URL and not try to bold it at all if it is. Maybe try to highlight the URL itself instead.

Also needs to not escape markdown in links.

Possible error cases:

• @Highlights add "foo " bar" in channel (intended: add "foo \" bar" in channel)
• @Highlights add "foo in channel (intended: add "foo" in channel)

Possible warning cases:

• @Highlights add foo in channel (intended: add "foo" in channel)

My "canonical" invite link for highlights won't create an integration role but it could theoretically matter at some point.

As far as I can tell, any role with a Role.managed value of true that the bot is a member of could only be an integration role.

The current Release workflow will overwrite the amd64 Docker image with the arm64 Docker image because it uses two separate build steps instead of one with two platforms specified. Before the next release, this needs to be fixed by either making the Dockerfile not require any build args to cross-compile successfully or using docker manifest to manually create a multi-architecture manifest for the tags to release.

Users shouldn't be allowed to add a keyword that contains the start of a mention (<@, <#), and keywords that include > shouldn't match when that > is the end of a mention.

Problem this feature solves
Sorting through multiple highlights from different guilds

Solution for this problem
This allows easy distinguishing when sorting through highlights for certain guilds. Applicable if the bot shares numerous guilds with the users

Additional context
The current embed specifies which guild it's in by including the guild name in the embed title. If the guild names are similar, this could cause confusion when attempting to sort through the previous highlights

Notifications for messages that were deleted should correspondingly be deleted.

Possible configuration options:

• Patience duration (how long to wait for a message in the same channel before sending a notification)

People shouldn't be able to add keywords that are obviously mentions, e.g. <@257711607096803328>. Any text inside of a mention shouldn't be highlighted either.

Tracing spans are getting dropped between when they're created and when they should be displayed in Jaeger's query interface. This causes obnoxious warnings:

Because parent spans can get dropped, traces can be much harder to interpret.

It's extremely unclear to me why this is happening; nothing I've been able to find on the topic applies to this scenario, as far as I can tell. Seemingly any span could be dropped, and it happens with essentially no load on any Jaeger components, making it unlikely it's a queuing problem.

At the moment, it's just logged as an error every time.

If the user has no past keywords, give them some kind of helpful tip on their first add/mute.

The current backup system doesn't allocate backups correctly. It should bucket old backups into separate months, trying to get one in each month.

Responses to commands should be deleted when the original message is deleted. It might also be worth deleting them after a long-ish delay automatically.

Without this feature, it's hard to keep your list of keywords private so nobody can intentionally annoy you with them.

Consider using a capture group for positive matches, if the group isn't captured then the match is ignored.

My main concern with this is ensuring that users can't exploit it easily. A lot of care will have to be taken, and limitations should be put on e.g. the length of allowed regexes. Regexes will have to be cached (if regex doesn't do that already) to avoid repetitive compilation costs. Ideally some benchmarks on how fast the current text-based matching is can be compared to regex-based matching, including with very complicated regexes.

Users should be able to opt-out of any notifications being sent because of their messages.

Possible name: followall

Some stat ideas

• Number of keywords added
• Number of users who've added keywords
• Number of times a keyword has been highlighted

Some errors, like those that occur when sending a notification about a keyword, are not reported to the configured webhook, despite others, like those that occur in commands, being reported as expected.

The text-based command system works alright, but it can get somewhat restrictive, and a GUI would probably be more intuitive.

Don't notify the user if they started typing or reacted to something in the same channel

Similar to #56 , using message commands to add blocked phrases could be a nice shortcut to the /ignore command

Environment variables are fine but a configuration file would probably be more organized and easier to expand. Sensitive information could possibly still be overridden by environment variables.

Since the /block command is semantically operating on a user, it would make sense to create a user command for blocking users.

Possible implementation: @Highlights add "foo" "bar" "baz"

Using quotes may be confusing, and it would probably be a good idea to add errors/warnings like #19.

If someone leaves the server, highlights should gracefully decide not to notify them, not log a 404 error about an unknown member.

E.g. highlight "deno" but not "deno DOM".

Perhaps @Highlights ignore "deno" in "deno DOM".

Alternatives:

• Make a field for the message link (could also make a field for the channel mention in that case)
• Add the message link to the highlighted keyword

Add a command that allows a user to block another user so their messages don't trigger highlights.