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.
jcahill
commented
7 years ago
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