New Meetingology for Matrix Clone In The Works

Community Matrix
,
1

Just wanted to drop a note here since the Matrix server is wholly unstable.

For the past few days, I have been working to get the Meetingology bot that Simon had made hastily to work. Only to discover it was written with ultra low-level matrix-nio directly making it beyond difficilt to work with for commands, reactions etc.

However, me going on my ever-chaotic coding binges, I have been working for a few days on a new Meetingology that uses a much more flexible niobot framework that makes command definitions, etc. easy.

Coupled with some aiosqlite to provide asynchronous DB interactions so we can track channels, meetings in channels, etc., and splitting out items into modules for commands, and a lot of more tech-flair I’m putting into this, we’ll theoretically be able to utilize Meetingology in multiple channels simultaneously.

If any of you on matrix notice a @Meetingology:darkchaos.dev or my other self @teward:darkchaos.dev around or in the matrix channels, its probably me still doing tests.

Hopefully though we’ll be able to get Meetingology meetings on Matrix working once Canonical teams get it stable again.

For now, all my testing and development take place on my darkchaos.dev homeserver, because the instability of the Ubuntu matrix space makes it impossible to test since we can’t send messages to channels among other things. I’ll post more detailed updates here as I work on and implement new things.

4 Likes
2

Currently confirmed working:

  • Commands in submodules
  • Database loading/closing during runtime
  • Defining administrators in the bot command line for “owner” admins.
  • Importing Meeting definitions at load time (into individual Meeting objects for easy Object Oriented referencing to items)
  • Making the bot post reactions to specific posts on specific cases (errors, on requests, etc.)
  • Separate modules for commands
    • General Commands (like ping and hello) usable by anyone
    • Admin Commands which includes sensitive commands that require elevated access (currently owner access only but can be expanded to a list of users who have admin access)
      • This will include an “add_meeting_channel” command which will add channels where the bot will be able to run meetings, and includes a ‘join’ to the room when added.
    • Debug Commands which have ungodly levels of access for testing things, restricted to bot owners only because you can get some really nasty data leaks with some of these.
  • Definition of “meeting rooms” and “administration rooms” is now a thing
    • “Meeting Rooms” are meetings where Meetingology will accept running meetings in.
    • “Administration Rooms” are where the bot can report issues to (errors, etc.) for admins to see

This is currently being worked on as my next focus burst:

  • Meeting Commands - Commands specific to running meetings.
    • Currently, the goal is to make it work for defined meeting types in meeting definition files. That way someone can do #startmeeting DMB or such and it’d autostart the Developer Membership Board meeting. We can even amend this further to specify which channels a meeting can be started in but that’s a later goal.
    • After we make it work with existing definitions, I’ll work on expanding to allow ‘generic’ meetings.
1 Like