@Xavion3 , figured I'd ping you on this. It might be a better place to discuss it than the chat.

I figure the first step to getting list comprehensions working is making the existing dice function return a list of numbers, and have everything else work relatively gracefully with that.

It might be time to start thinking about numpy. Having arrays as a native datatype enables stuff like matrix multiplication, which numpy would benifit.

Spawn a new process for each request.

Implement a voting system that uses anon votes.

I would like it to auto-emote so that people can click emote options, along with voting via PM/channel msg.

The ability to purge a channel every so often.

It has come to our attention that 5*5*5 renders as 555 in discord.
Supporting expressions wrapped in

```Code blocks```
`code block`

would make it a lot easier to have pretty input.

Some work has been done on the multiprocessing branch. Should do exactly what is says on the tin, spawn the parser in a subprocess using multiprocessing and kill the subprocess if it's still running after 10-ish seconds.

Right now that's mostly working, but the subprocess is never returning for some bizarre reason.

Overview/goals

We initially tried to implement chat bridging by simply running matterbridge. We ran into some technical issues that looked like they'd take more time than simply implementing the required functionality ourselves in python, especially as we don't seem to have any competent golang developers volunteering their time.

It was determined that python, although less performant, is probably a better tool for the kind of text-munging and data-processing that this project need. Python 3.6's asyncio framework removes a lot of the issues with writing chat bots/interfaces in python. It also has mature libraries for accessing most of the services we need to.

Integrating and standardizing the featuresets of many distinct chat clients is hard, but there's one project that has made an effort to do exactly that. Jabber/XMPP. It also "represents some of the worst excesses of the XML mindset" according to some. It has not been a popular protocol and has many detractors. Still, it seems like the best thing going, and the python bindings are mature enough to mostly abstract the pains of XML away.

Our intent is to implement an interface (a "server component") to these various servers, using the sleekxmpp library. The XMPP standard uses nested "servers", or server components, to implement much of it's functionality. Even something as simple as chat-rooms normally goes on a sub-domain.

This kind of architecture is crazy, and bad, and horrible UX. But it does allow us a ridiculous amount of flexibility. We act as a registry, but the actual bridge could be entirely controlled by the server in question. Or written in entirely different languages.

XMPP provides a standard spec that all bots must conform to.

Server component goals

Delete a user comment and repost as rot13