@Undo Yep. We could probably just include it in version control, to be honest. If it gets corrupted, we can just manually pull a new copy from metasmoke to Smokey.
@Undo "bob added joe ten minutes ago because chat.stackexchange.com/..."
There's an API for GH, and I think they have a python lib. However, we're not going to need to push it up that much - you could just do it manually from the Pi every X time.
Or, if the GH credentials are cached, just run the system commands.
I really like having Smokey be simple. In some ways, it's too complicated for my liking. But I really really don't want it to rely on a webapp that goes down every few days
@hichris123 No, the idea is that Smokey is still self contained and we can still edit things through GH if we want. But we can also edit them through metasmoke and not have to go through a commit-pull cycle
In essence, Smokey does have the full privileged users list available to it. But we have a command to tell it to update that list by consulting metasmoke, without having to pull from GH.
Really, I think this wouldn't be worth it on its own. But it's also our ticket to moving the Giant List of Regexes out of code, which would be really nice.
We really shouldn't have an array of a few hundred domains in source code
Throw that thing in a CSV or something
And if we're doing that, why not build a passable UI?
I'm only too aware that MS goes down a lot - but if we cache every list that we pull from MS on disk, that leaves Smokey self-contained if when MS does die.
@Undo This isn't change-averse. I don't believe that the addition of a third-party dependence would be net-beneficial. Obviously, it would make it easier to add regexes & privileged users. But making a self-contained bot dependent on another system and not having a clear source of truth is a recipe for disaster. Even being dependent on the SE API/websockets causes a crash or two each day.
