eevee/dywypi

Python IRC bot built atop asyncio

dywypi's Issues

Calculator plugin

Standard stuff. I'd rather not write my own infix evaluator, though. Google has an undocumented calculator API, but it's part of iGoogle which I think is going away. :(

Much better mapping of responses to IRC messages

There are, I believe, three major classes of problems here:

1. More or less simple responses, e.g., you send a NAMES and get back NAMREPLY + ENDOFNAMES. The response starts with the first NAMREPLY and ends with the ENDOFNAMES.

2. Compound, complex responses. For example, joining a channel starts with a JOIN, includes a topic response, and finally ends with a names response. So a names response might end both a NAMES or a JOIN. Not too much harder; just have to see who expected to get it first.

3. Super ambiguous responses, such as you might get from... PRIVMSG! The problem is that PRIVMSG doesn't reply on success, so if you use PRIVMSG three times and get back a single error, which message did it correspond to? Also, assuming we want error replies to become exceptions, how long do we wait until we assume success?

   It's possible to guess a lot here, but I'm not sure how much harm the guessing will do, or how much it really matters anyway. Some ideas are:

   • Keep track of how long it generally takes to get replies, and use some reasonable factor of that as a timeout.

   • Gather all the known error replies from all the popular servers and add special-casing for all of them. For example, if we send three messages, only one of them contains IRC formatting, and we get back only one ERR_CANNOTSENDTOCHAN, it's a reasonably safe bet which of them is the culprit.

     Which, of course, brings up another problem: ERR_CANNOTSENDTOCHAN is really meant for when you're banned and can't talk to a channel at all, but inspircd's +c (and I suspect others) reuses the same code to avoid relying on special client support. So how do we distinguish this from being banned, having the first message fail, and then a lag spike? inspircd is kind enough to use a different message, but scraping user-facing error messages sounds like not a great idea...

Zooming out a bit, should yield from client.say() even risk raising an exception in the first place?

More generally, what should happen with unexpected error replies?

What if we must get a particular reply but never do?

Well, wait, I think I can handle that last one. I'm pretty sure the IRC protocol is intended (if not explicitly stated) to send replies in the order the messages were received, with no interleaving. So if we send messages A B C, and we get a reply that could only be for A followed by a reply that could only be for C, we know B just didn't get a response, and/or there's a severe bug somewhere. "Spontaneous" messages like NOTICE can of course happen at any time. (Question: can a PRIVMSG come within a JOIN, before the ENDOFNAMES comes back? I swear I've seen this happen in irssi before, but I don't know if it's the protocol being wacky or irssi just lagging a bit before it shows the names list.)

irc is hard

URL preview plugin

These are neat. Use an API where one exists: YouTube, imgur, etc.

Maybe collect URLs that have been seen before and do something useful with that information, gasp.

Pokédex plugin

It's what old dywypi is most used for, I think. Depends on having a usable API, though.

Consider straight.plugin

Current hand-rolled stuff is a clusterfuck.

http://straightplugin.readthedocs.org/en/latest/

Your setup.py sucks, yo

The README claims that pip install works, but it doesn't, because I never bother keeping setup.py up to date with package-finding, goddamn. At the moment it doesn't include dywypi.plugins, for example. (Might just be find_packages not finding a non-package. If so, just add an __init__.py, since a subpackage can't actually be a namespace package anyway.)

Authentication

Via NickServ, tyvm.

Configuration

Right now stuff is hard-coded. Clearly needs to not be.

Markov plugin

Of course.

Support DCC

Merge tulip branch already

Yeah come on.

Main blocker is that there's some unfinished stuff on my laptop, which isn't even really a blocker, so I don't know.

I guess it'll nuke the history of all the downstreams (ha, ha)

Finish event handling

This is in a highly ambiguous state at the moment.

Consider panglery, perhaps.

Color support

Something that doesn't suck to use, and that works both in the shell and in IRC.

Move core plugins to dywypi_plugins, make plugin infra a package

Probably a good idea, since the plugin support stuff is growing fast enough that it'll exceed the bounds of a single file pretty soon.

Support async (stdin/out) pipe access.

Support plugins that can take a json formatted message to std-in and emit a json formatted reply to std-out.

I started an implementation but gave up for unrelated reasons, I'll be more than happy to point folks in the right direction on this.

Core "plugin"

This should contain all the basic functionality not directly related to the bot's existence, like user tracking and authentication and whatever.

User tracking

Useful backbone for some other stuff: auth, logging, rate limiting, etc.

Support CTCP

Someone else is already working on this, which is great because I don't know how it works!

Redirects

>, for sending output to a particular channel or user. (Potential for abuse here?)

|, for piping one command into another. (Where does the second command consider the input as having come from? Do commands actually support a "stdin" for this purpose?)

Finish shell

• Should be optional, or only run in "debug mode", or something.
• Should have some slightly more useful information about what the bot is doing, though this might just be a problem of logging.
• Should have special shell-only commands.
• Syntax coloring?
• Exit more cleanly; I think it's a bit messy right now.
• I think there are some half-finished dummy objects that pretend the shell is its own network; could stand fixing that.

Support alternative backend I/O thingamajigs

For example, irkerd, or that one project that communicates over a 0mq socket, or that one project that uses a whole virtual filesystem, or whatever. It would be nice if the bot could be talked to in whatever way you please.

Persistent storage

Obviously necessary for a variety of things. Not sure what form this should take yet. Using a whole Postgres db for a bot seems kinda heavy-handed.

asyncio branch pegs a core when server goes away

I assume it's in a crazy busy loop doing... something. Would be nice to not do whatever that is.

Help plugin

Should be able to enumerate existing plugins and how to use them.

Support parsing IRC formatting

And offer it as an argument alongside message and args and whatever. Maybe do it automatically for any IRC message's final argument...?