I've been trying to write a good description of debug-me, and here's what I've got so far:

Short description: "secure remote debugging"

Long description:

Debugging a problem over email is slow, tedious, and hard. The developer needs to see the your problem to understand it. Debug-me aims to make debugging fast, fun, and easy, by letting the developer access your computer remotely, so they can immediately see and interact with the problem. Making your problem their problem gets it fixed fast.

A debug-me session is logged and signed with the developer's Gnupg key, producing a chain of evidence of what they saw and what they did. So the developer's good reputation is leveraged to make debug-me secure.

When you start debug-me without any options, it will connect to a debug-me server, and print out an url that you can give to the developer to get them connected to you. Then debug-me will show you their Gnupg key and who has signed it. If the developer has a good reputation, you can proceed to let them type into your console in a debug-me session. Once the session is done, the debug-me server will email you the signed evidence of what the developer did in the session.

If the developer did do something bad, you'd have proof that they cannot be trusted, which you can share with the world. Knowing that is the case will keep most developers honest.

I think that's pretty good, and would like to know your thoughts, reader, as a prospective debug-me user.

Most of today was spent making debug-me --control communicate over a socket with the main debug-me process. That is run in a separate window, which is the debug-me session control and chat window. Things typed there can be seen by the other people involved in a debug-me session. And, the gnupg key prompting stuff will be done in that window eventually.

Screenshot of the first time that worked. The "user" is on the left and the "developer" is on the right.