Multi-protocol lazybot was a poor idea. It's better that we focus on IRC. Besides, the Twitter experiment was a huge failure that I don't even want to talk about. Some of this code still exists in hidden places, while not effecting anything. We should eliminate all of this dead code.

Like fortunes.clj

Haven't tried it as the exploit isn't entirely trivial, but I suspect that users can use $findfn to call arbitrary java code. Need to look at making clojail.core/dotify public.

Yes.

Either wolfram alpha or true knowledge. Probably the latter.

The fucker is fickle.

Of course, the new irclj isn't ready yet, so this one can wait.

Right now, our configuration is a mess. Plugins just do whatever the hell they want with the configuration file and nothing is standard. Besides that, half of our keys don't make any sense.

I propose the following configuration conventions/guidelines:

• A plugin should never have configuration keys in the top level of the configuration file. Instead, they should have their configuration in a key named after the plugin. For example: {:clojure {:prepends ..}}. This should be true regardless of whether or not a plugin only has a single configuration key. It needs to be standardized. There is no way to enforce it, but we can certainly encourage it.
• Plugins should document their configuration keys. I will create a plugin description file and being documenting the existing plugins.
• Plugins should never die if configuration is not set. It is okay to fail if it is set incorrecly, but only if it would be inconvenient to die gracefully. It should never die because a key simply isn't set.
• A huge problem with our configuration is that you have a top-level :plugins key and one for every server. This is ugly and inconvenient. It makes more sense for each server to have a :plugins key, but not a top level key. lazybot should be intelligent enough to know what to do here, and there should be a way for 'all' plugins to be loaded without copying them each and every time or wrapping the configuration in a let.

Currently I do not know how to setup java.policy file @ heroku.
When I eval some code, then bot give me...

• java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)

Can we avoid this step, even at the cost of the unsecured bot?

• IMPORTANT: If you load the clojure plugin, you must rename and move "example.policy" to "~/.java.policy" to avoid some troublesome security errors!

e.g. Disable all but the most useful plugins. Also need to test it and make sure it is working fine.

Need a yammer lib first.

Each channel should have a list of watched GitHub repos where newly-opened issues could trigger a lazybot announcement.

The idea would be to configure repositories and people who are allowed to use those repos and allow those people to create issues from within IRC. We need a better permission system first, but we could implement this without it.

Not necessarily the plugins. This issue can be closed when the entire core of lazybot has been documented well.

When running

lein uberjar

I get the response

Compiling lazybot.run
Compilation succeeded.
Release versions may not depend upon snapshots.
Freeze snapshots to dated versions or set the LEIN_SNAPSHOTS_IN_RELEASE environment variable to override this.

And no uberjar is created.

I believe this is due to one of the dependencies being hobbit "0.1.0-SNAPSHOT"

While it may be a bit more annoying to do, we should be passing around a ref that contains the IRC ref and can be modified with configuration information and stuff. What we're doing now is just plain dirty.

!fcst Prague, Spain
Raynes: 8:00 PM CEST
Raynes: TODAY: Unknown. High 23°C (73°F). Winds 0 kph North
Raynes: TONIGHT: Chance of Rain. High 22°C (71°F). Winds 32 kph WSW

Like $foo bar && $baz quux or something. The challenging part is getting a syntax that isn't insane but also doesn't clash with normal commands.

All plugins that use an arrow should use the one in the clojure plugin. Maybe def it in utilities?

Because it is nuts. And because I said so.

The shorturl plugin doesn't appear to be working for bitly, but it does appear to be working for isgd.

Here are some commands and the responses:

@shorten bitly http://google.com
-- No response -- 

@expand http://bit.ly/LmvF
-- No response -- 

@shorten isgd http://google.com
http://is.gd/5JJNDX

@expand http://is.gd/5JJNDX
http://google.com

@shorten none http://google.com
No URL shortener by that name was found.

Slightly complicated because if you fork the JVM, you end up with a logless bot. The restart command would need to make the bot log to a file.

We need to figure out a way to centralize reading of the configuration file. We load it here there and everywhere, and it isn't consistent. If we have it loaded in a single place (the IRC ref), we'll be able to access it on the fly, and when we reload the bot, the configuration will be reloaded as well. We can also reload the configuration and not the whole bot at a single time, and we can expect it to Do The Right Thing most of the time.

With ororo.

Challenging because coming up with a syntax is difficult. Your first inclination is to allow for factoid commands/queries to be like lazybot: foo is bar but that doesn't really work in lazybot. The problem is that command prefixes are arbitary strings. This means that lazybot: can actually be a command prefix in which case whatever foo is could be a command, in which case the commands and hooks would clash. I guess one option here is to modify the command/hook system so that hooks only trigger if a command isn't also triggered, but I don't want to do that. I think that the best compromise here is to just make the factoid system be a command.
e.g.

$fact foo is bar
$whatis foo

Automatic sed is cute, but it annoys people. Let's make this automatic behavior configurable and off by default.

Each channel should have a GitHub repo where Lazybot would look up references to issues and reply with a description and link.

Perhaps initially it would only be triggered by direct requests to lazybot:

<technomancy> lazybot: #732
<lazybot> preview8 can't find clojure/tools/nrepl/server.clj when trampolined - https://github.com/technomancy/leiningen/issues/732

It could respond to inline issue references as well using a syntax that's less likely to be triggered accidentally; perhaps ##732.

A more specific reference like Raynes/lazybot#77 would allow you to refer to an issue other than the channel's primary repository.

Help isn't working properly. Whenever you try to get help, it always looks up help in the topics, rather than return help for the specific command you're trying to use.

Right now, Irclj does absolutely nothing when the connection times out except go into a coma. We need a way to make connections timeout, and know when we've disconnected in order to handle disconnects the right way.

Google Translate is no longer free. We need to either delete the plugin or find a new service to use in place of it.

The way lazybot loads plugins is bizarre and buggy. For example, loading a plugin from IRC doesn't work if the plugin wasn't already required at lazybot's startup. This is silly. Fix it.

Title.

http://logs.lazybot.org/irc.freenode.net/%23clojure/today.txt

There is some strange bug that is causing the Github plugin to fail if the bot hasn't been reloaded at least once after starting up on my and Alan's VPS (the primary lazybot instance). I've been having some issues with ports that have kept me from reproducing things locally, but Alan plans to try to reproduce it soon.

Channel keys should be stored in the :channels map if they exist. That way, users have a way of knowing whether or not they're in a private channel without having to remember it themselves.

It'd be cool to have some sort of time tracking integrated with the bot. Possibly integrated with a service like toggl or harvest.

It would be able to do the following:

• Start and stop a timer for a task with a name.
• Tell you how long you've been working on something.
• Give you analytics about what you've done in a given time frame. Today, yesterday, this week, last week, this month, last month, February 25 -> August 14th, etc.

Currently, you always have to login. This isn't always necessary, as some people have relatively constant and unique hostnames. The hostnames could be used rather than traditional login for some people, and would in turn kill the need for some admins to login all the time.

If you use the !reload command with all or most plugins loaded, the bot's memory usage grows by about 2-3 megs. This is bad.

We should improve the login system to make it possible to expand on permissions. I think this capability might already exist, but we should definitely make it easy to use.

Links to Raynes/lazybot and Raynes/sexpbot

We've already got an embedded webserver, so why not write a fancy interface to the log files?

The process keeps spinning with 100% CPU usage until you forcefully kill it, which is not exactly ideal behaviour.

Right now, all we can do with the permission system is declare users to be either admin or regular user. We need to expand this out and improve it so that we can have an extensible system capable of very specific permissions. This way we can have sets of permissions for users that plugins can add to and check for as well as two basic permissions:

• user: for regular users
• admin: for administrators who are trusted with the scariest commands.

The idea is that it would be possible to give certain non-admin users more dangerous and specialized permissions. For example, a plugin foo could check for its own special permission, like permission foo.

Replace the shorturl plugin with one that uses hobbit and is intelligent. Also, add a generic is-gd shortening function to lazybot.utilities for usage in plugins and other lazybot code.

Some ideas:

• Issues
  • View contents of issue.
  • Number of issues.
  • Open/close issues?
    • This might be plausible if bot instance x has its own Github account and is made a collaborator on Github. You wouldn't want to allow authentication with Github from IRC unless you used oauth2. If you used basic auth, you'd be able to see the passwords via console logging.
  • Alert when issue is created.

It would be neat if there was a way to embed evaluation in a message.

<Raynes> Well, you could always do &|(println "blah")|&

The &||& used is just an example.