bingobot/main.go

71 lines
1.3 KiB
Go
Raw Normal View History

2024-11-06 11:34:45 -08:00
package main
import (
"flag"
"log"
"os"
"os/signal"
"github.com/bwmarrin/discordgo"
"gitlab.com/whom/bingobot/internal/config"
"gitlab.com/whom/bingobot/internal/logging"
Internal event state tracking and Pub/Sub model Internal state tracking: This commit introduces the concept of internal events. The thought here is that bingobot will track its current state not by variables set from incoming discord event data but rather from a cache of internal events that represent digested and simplified observations made and actions taken by internal code. Currently the events that are defined include the following: - UserActive Events: These events are intended to be generated when a user is noticed to have been sitting in a voice chat for more than 10 minutes, however they can be generated in response to anything that signifies that a user has been active - Challenge Events: These events signify that a user has been challenged. They are intended to act as a primitive form of restraint from using bot features. It is intended that these are made only as a response to a successful vote. - Restore Events: These events signify that a user has been restored to non-challenged status. It is intended that this only happens in response to a successful vote. - Vote Events: These events serve as the primary means of consensus building, and represent the state of a single active ongoing or finished vote. Currently the events are cached for 10 days and then discarded, but future work will add an on disk document storage for old events should any functionality desire it. This internal event cache is intended to be the authoritative source of truth for information about user permissions, vote results, and any additional future functionality that relies on shared state. It is accessed through a GetMatchingEvents function that accepts both an event type and a map of optional metadata filters. See state_test.go for examples of this functionality. In addition to the cache search function there is also a Publisher/Subscriber setting elaborated on below. Pub/Sub system: This commit also introduces a Pub/Sub system for other internal packages and feature modules to recieve live events and continually process updates from our code as opposed to just handling discord events. - PublishEvent() In this specific implementation anyone may become a Publisher by calling PublishEvent() on any structure that implements the Event interface. This provides for modules being able to define their own event types (so long as they also extend the central enum of EventType in state.go). - SubscribeWithHistory() This returns a channel to the caller that returns copies of any event matching the input event type. This channel will be prepopulated with up to 256 most recent events already in the cache. Future work will make this number configurable. Each event published will be sent down all relevant channels at publish time. - Subscribe() This returns a channel to the caller, as SubscribeWithHistory also does, with the sole caveat that there are no historical "old" cached events prepopulating the channel. Finally, this commit also contains tests Signed-off-by: Ava Affine <ava@sunnypup.io>
2024-11-06 14:41:49 -08:00
"gitlab.com/whom/bingobot/internal/state"
2024-11-06 11:34:45 -08:00
)
var (
Token = flag.String("token", "", "Bot authentication token")
App = flag.String("app", "", "Application ID")
Guild = flag.String("guild", "", "Guild ID") // Do we want it to be tied to one server?
appConfig *config.AppConfig
2024-11-06 11:34:45 -08:00
)
func main() {
flag.Parse()
if *App == "" {
log.Fatal("application id is not set")
}
var err error
appConfig, err = config.Parse()
2024-11-06 13:32:37 -08:00
if err != nil {
log.Fatal(err)
}
logging.Init(appConfig)
2024-11-06 14:19:45 -08:00
err = startBot()
if err != nil {
log.Fatal(err)
}
2024-11-06 11:34:45 -08:00
}
2024-11-06 14:19:45 -08:00
func startBot() error {
Internal event state tracking and Pub/Sub model Internal state tracking: This commit introduces the concept of internal events. The thought here is that bingobot will track its current state not by variables set from incoming discord event data but rather from a cache of internal events that represent digested and simplified observations made and actions taken by internal code. Currently the events that are defined include the following: - UserActive Events: These events are intended to be generated when a user is noticed to have been sitting in a voice chat for more than 10 minutes, however they can be generated in response to anything that signifies that a user has been active - Challenge Events: These events signify that a user has been challenged. They are intended to act as a primitive form of restraint from using bot features. It is intended that these are made only as a response to a successful vote. - Restore Events: These events signify that a user has been restored to non-challenged status. It is intended that this only happens in response to a successful vote. - Vote Events: These events serve as the primary means of consensus building, and represent the state of a single active ongoing or finished vote. Currently the events are cached for 10 days and then discarded, but future work will add an on disk document storage for old events should any functionality desire it. This internal event cache is intended to be the authoritative source of truth for information about user permissions, vote results, and any additional future functionality that relies on shared state. It is accessed through a GetMatchingEvents function that accepts both an event type and a map of optional metadata filters. See state_test.go for examples of this functionality. In addition to the cache search function there is also a Publisher/Subscriber setting elaborated on below. Pub/Sub system: This commit also introduces a Pub/Sub system for other internal packages and feature modules to recieve live events and continually process updates from our code as opposed to just handling discord events. - PublishEvent() In this specific implementation anyone may become a Publisher by calling PublishEvent() on any structure that implements the Event interface. This provides for modules being able to define their own event types (so long as they also extend the central enum of EventType in state.go). - SubscribeWithHistory() This returns a channel to the caller that returns copies of any event matching the input event type. This channel will be prepopulated with up to 256 most recent events already in the cache. Future work will make this number configurable. Each event published will be sent down all relevant channels at publish time. - Subscribe() This returns a channel to the caller, as SubscribeWithHistory also does, with the sole caveat that there are no historical "old" cached events prepopulating the channel. Finally, this commit also contains tests Signed-off-by: Ava Affine <ava@sunnypup.io>
2024-11-06 14:41:49 -08:00
state.DiscordSession, _ = discordgo.New("Bot " + *Token)
2024-11-06 11:34:45 -08:00
Internal event state tracking and Pub/Sub model Internal state tracking: This commit introduces the concept of internal events. The thought here is that bingobot will track its current state not by variables set from incoming discord event data but rather from a cache of internal events that represent digested and simplified observations made and actions taken by internal code. Currently the events that are defined include the following: - UserActive Events: These events are intended to be generated when a user is noticed to have been sitting in a voice chat for more than 10 minutes, however they can be generated in response to anything that signifies that a user has been active - Challenge Events: These events signify that a user has been challenged. They are intended to act as a primitive form of restraint from using bot features. It is intended that these are made only as a response to a successful vote. - Restore Events: These events signify that a user has been restored to non-challenged status. It is intended that this only happens in response to a successful vote. - Vote Events: These events serve as the primary means of consensus building, and represent the state of a single active ongoing or finished vote. Currently the events are cached for 10 days and then discarded, but future work will add an on disk document storage for old events should any functionality desire it. This internal event cache is intended to be the authoritative source of truth for information about user permissions, vote results, and any additional future functionality that relies on shared state. It is accessed through a GetMatchingEvents function that accepts both an event type and a map of optional metadata filters. See state_test.go for examples of this functionality. In addition to the cache search function there is also a Publisher/Subscriber setting elaborated on below. Pub/Sub system: This commit also introduces a Pub/Sub system for other internal packages and feature modules to recieve live events and continually process updates from our code as opposed to just handling discord events. - PublishEvent() In this specific implementation anyone may become a Publisher by calling PublishEvent() on any structure that implements the Event interface. This provides for modules being able to define their own event types (so long as they also extend the central enum of EventType in state.go). - SubscribeWithHistory() This returns a channel to the caller that returns copies of any event matching the input event type. This channel will be prepopulated with up to 256 most recent events already in the cache. Future work will make this number configurable. Each event published will be sent down all relevant channels at publish time. - Subscribe() This returns a channel to the caller, as SubscribeWithHistory also does, with the sole caveat that there are no historical "old" cached events prepopulating the channel. Finally, this commit also contains tests Signed-off-by: Ava Affine <ava@sunnypup.io>
2024-11-06 14:41:49 -08:00
err := state.DiscordSession.Open()
2024-11-06 11:34:45 -08:00
if err != nil {
logging.Error("could not open discord session", "type", "error", "error", err)
2024-11-06 14:19:45 -08:00
return err
2024-11-06 11:34:45 -08:00
}
logging.Info("shutting down gracefully", "type", "shutdown")
2024-11-06 14:19:45 -08:00
2024-11-06 11:34:45 -08:00
sigch := make(chan os.Signal, 1)
signal.Notify(sigch, os.Interrupt)
<-sigch
logging.Info("shutting down gracefully", "type", "shutdown")
2024-11-06 11:34:45 -08:00
Internal event state tracking and Pub/Sub model Internal state tracking: This commit introduces the concept of internal events. The thought here is that bingobot will track its current state not by variables set from incoming discord event data but rather from a cache of internal events that represent digested and simplified observations made and actions taken by internal code. Currently the events that are defined include the following: - UserActive Events: These events are intended to be generated when a user is noticed to have been sitting in a voice chat for more than 10 minutes, however they can be generated in response to anything that signifies that a user has been active - Challenge Events: These events signify that a user has been challenged. They are intended to act as a primitive form of restraint from using bot features. It is intended that these are made only as a response to a successful vote. - Restore Events: These events signify that a user has been restored to non-challenged status. It is intended that this only happens in response to a successful vote. - Vote Events: These events serve as the primary means of consensus building, and represent the state of a single active ongoing or finished vote. Currently the events are cached for 10 days and then discarded, but future work will add an on disk document storage for old events should any functionality desire it. This internal event cache is intended to be the authoritative source of truth for information about user permissions, vote results, and any additional future functionality that relies on shared state. It is accessed through a GetMatchingEvents function that accepts both an event type and a map of optional metadata filters. See state_test.go for examples of this functionality. In addition to the cache search function there is also a Publisher/Subscriber setting elaborated on below. Pub/Sub system: This commit also introduces a Pub/Sub system for other internal packages and feature modules to recieve live events and continually process updates from our code as opposed to just handling discord events. - PublishEvent() In this specific implementation anyone may become a Publisher by calling PublishEvent() on any structure that implements the Event interface. This provides for modules being able to define their own event types (so long as they also extend the central enum of EventType in state.go). - SubscribeWithHistory() This returns a channel to the caller that returns copies of any event matching the input event type. This channel will be prepopulated with up to 256 most recent events already in the cache. Future work will make this number configurable. Each event published will be sent down all relevant channels at publish time. - Subscribe() This returns a channel to the caller, as SubscribeWithHistory also does, with the sole caveat that there are no historical "old" cached events prepopulating the channel. Finally, this commit also contains tests Signed-off-by: Ava Affine <ava@sunnypup.io>
2024-11-06 14:41:49 -08:00
err = state.DiscordSession.Close()
2024-11-06 11:34:45 -08:00
if err != nil {
logging.Error("could not close discord session gracefully", "type", "error", "error", err)
2024-11-06 14:19:45 -08:00
return err
2024-11-06 11:34:45 -08:00
}
2024-11-06 14:19:45 -08:00
return nil
2024-11-06 11:34:45 -08:00
}