Closed onerandomusername closed 3 years ago
Asked to commment my thoughts on this issue.
Removal of the site is fine, but there still needs to be a way to:
Threads do eradicate the necessity of a website used for log viewing.
I think we should. A website is a massive barrier to entry, requiring not only DNS, potentially a domain purchase, extra configuration on the bot end, but also requires managing the security of something internet connected (just a bot does not have to field responses to potentially malicious requests). We can also heavily trim down our dependencies, avoid implementing all sorts of access controls, the list goes on.
Site is a big project and if we can get away with not having it we'll but much more lightweight, easier to use, and I won't have to manage a login session with discord to view archived modmail threads. It also means the bot will not need channel delete perms which is really nice from a safety + security perspective.
Thread search can probably be implemented as a command--by user, or other threads by the current thread user, depending on whether it's invoked with arguments, which should be fairly simple. I'm on the fence about wanting it to be a slash command vs a regular command, we'll probably want to try both ways to figure it out. A regular command is more immediately useful and we don't have to worry about dpy support so let's do that first?
There's a few ways to link into threads as they stand--despite the decisions that have gone in the implementation on discord's end. We can link to messages in the channel, and we can link to the root message in, I think, what we'll plan to be the #modmail-logs or #modmail-root or something channel. At least from there you can jump into a thread (and we can bypass discord's ugly message link view with an embed), although at the moment mobile has real issues and we'll really want to link directly to a message within the thread. We know this works for archived threads, and deleting threads should be marked over towards admin/nonautomated as threads use archive/unarchive for activity rather than present/deleted as most bots do currently.
We may need to consider keeping threads auto-unarchived. Not sure what discord will want to say about that. It'll probably come up sooner rather than later, but at least there's a 24 hour timer so worst case is someone just needs to poke in once a day, which isn't too bad. We can also fire off a ping to grab moderator attention in the case that a channel has been left unattended and this could be considered a feature of sorts.
@onerandomusername does dpy v2/master currently support threads? IIRC it does, and if it does then we should definitely nuke the website for now and restore it via undoing the commit later if we find out that we end up needing it later.
We should then get out a MVP to prove the concept with threads and whatever issues are definitely hiding around the corner waiting for us.
@onerandomusername does dpy v2/master currently support threads? IIRC it does, and if it does then we should definitely nuke the website for now and restore it via undoing the commit later if we find out that we end up needing it later.
Yes, King Arthur in Python Discord uses d.py master and was able to respond inside a thread.
So far, there's no one here against removing the website, @Shivansh-007 ?
Thread search can probably be implemented as a command--by user, or other threads by the current thread user, depending on whether it's invoked with arguments, which should be fairly simple.
@bast0006 Would this be done with a database, in order to log threads? It's only possible to fetch up to 100 messages at a time per channel, and we would need a minimum of one request per user. (This is probably worth making into another issue, to be honest.)
I'm on the fence about wanting it to be a slash command vs a regular command, we'll probably want to try both ways to figure it out. A regular command is more immediately useful and we don't have to worry about dpy support so let's do that first? @bast0006 Once we have library support, it's worth looking into slash commands. Conversely, we could also use a different third party if discord.py doesn't deliver soon. We should use normal commands for the time being.
@bast0006 Would this be done with a database, in order to log threads? It's only possible to fetch up to 100 messages at a time per channel, and we would need a minimum of one request per user. (This is probably worth making into another issue, to be honest.)
@onerandomusername we'd want this to be searching the database, yeah. It's not smart to cache all the archived threads in RAM, and setting up redis is really overkill for this use case. We can work it easily into a regular DB query and be done with it, and db-query-on-command is not worth overthinking.
@bast0006 Once we have library support, it's worth looking into slash commands. Conversely, we could also use a different third party if discord.py doesn't deliver soon. We should use normal commands for the time being.
Agreed. Not worth adding complexity at this stage
After internal discussion, I've decided that there will not be a website or a dashboard.
This is because modmail threads will also be Discord threads. Using these allows for the contents of the thread to be archived in discord. No longer do we need to have a website, or most of the database.
The database is still necessary for bot configuration, and to store some metadata about threads to improve ease of use, but other than that, threads and such will all live in discord.
Tasks: