lykos icon indicating copy to clipboard operation
lykos copied to clipboard

Rewrite the IRC library

Open Vgr255 opened this issue 5 years ago • 2 comments

We're currently using a very old (2010-ish) IRC library, and we've just bolted stuff on top of other stuff for a long time. Unlike the rest of the bot which is better handled through procedural refactors, we will be better off if we fling the current library into the sun and make a new one. Or also adapt an existing one, that works too.

The new library must:

  • Support Python 3.5+ (supporting older versions is fine too, but 3.5 is the minimum)
  • Support TLS connections and SASL external (client certificates)
  • Use asyncio
  • Support having multiple instances of the client connected to the same server (but with different nicks) running simultaneously
  • Not assume that it's the only thing running in the asyncio event loop. We'll have other non-IRC stuff in there too. Notably, this means that each time control is passed to the IRC library, it should fully process one thing only (not half-process a thing and return control to us, or work through its entire backlog of things before returning control to us)
  • No flood control/throttling in the lib itself; our scheduler (main loop) will take care of that

Ideal, although not required:

  • Maintained in a separate repo that we can pull from to update the library
  • Automatic netsplit detection and handling
  • Automatic reconnection if disconnected from server
  • Support the following capabilities: account-notify, account-tag, chghost, extended-join, multi-prefix, userhost-in-names

Fancy stuff that's not really needed but would be nice:

  • Ability to stay connected while the rest of the bot restarts (don't focus on this immediately if you're going to do it at all)

What this library does NOT need to do:

  • Keep any form of API compatibility with the current library

If using an existing library, it's preferred if we don't have to make a fork of it to customize it to our liking. That way we can easily keep using the upstream as they update to support more things (like ircv3 features). This means that the library we're using should have maintainers who are actually present and are willing to accept pull requests to add additional functionality we may require.

If you're interested in doing this, let us know in #lykos and we can get you a repo under the lykoss group on GitHub.

Vgr255 avatar Aug 13 '18 23:08 Vgr255

Could we maybe use https://github.com/jaraco/irc?

Fudster avatar Jan 15 '19 08:01 Fudster

No SSL support in the asyncio version, so no that won’t work. If we’re usung an existing lib I want to be able to use it as-is instead of making a fork and customizing.

I’ll update the description soonish with a more up to date list of requirements.

skizzerz avatar Jan 15 '19 13:01 skizzerz