Currently, the following BitMessage API connection details are hard coded:

URL: http://localhost:8442/
Username: mirror_messaging
Password: 123

We should make these configurable values, and not rely on these hard coded defaults.

Users should be able to specify the network interface they wish Mirror Messaging to bind to on start up.

This could be added in the config file. See issue #6.

Can use a themes folder in the Mirror Messaging user folder and a theme variable in the configuration file to indicate the currently active theme.

The POST data for sending a new message on the compose page should be validated before being sent to the BitMessage API.

Show (optional) detailed network information (such as number of connected peers) in the sidebar.

Create config file stored in user home directory

Mirror Messaging currently has no ability to interact with the outgoing addresses stored in BitMessage.

We need to add pages for standard CRUD of addresses that correctly integrates with the BitMessage API. Perhaps call the section 'Contacts' to be more user friendly.

Given that chans are now officially supported in PyBitmessage, we could implement some form of forum board style view for chan messages specifically.

This would also mean that chan messages should not be shown in the Inbox view.

The Tor Browser Bundle bundles together Firefox and Tor together to make a very easy to use and solution for most users.

We should bundle BitMessage with Mirror Messaging so that the following are true.

1. The bundled BitMessage should run on a different ports than defaults (both the main protocol port and the local API port).
2. The bundled BitMessage should be configured in 'portable mode', so that the BitMessage files are stored in the Mirror Messaging directory and not in the main user directory.
3. The bundled BitMessage should be started automatically by Mirror Messaging. This should only occur if the bundled BitMessage is not already running, which can be checked by a simply BitMessage API call to one of the test functions.
4. The bundled BitMessage should be configured to run in the hidden daemon mode and thus not present the BitMessage GUI to the user.

You should be able to mark a message a unread. This should be possible:

• On a per message basis
• In bulk via on the Inbox page via a series of checkboxes

Show the level of connectivity to the BitMessage network.

This requires a further 'set_read_status' (or similar) API function to be created and accepted into PyBitmessage.

Work out of the feasibility of and hopefully implement some form of conversational view.

Ideas:

• Store a conversation_hash against each message id, which is the same for the conversation pair
  ** For inbox messages sha1(from+to)
  ** For sent messages sha1(to+from)

We should use a fluid layout for the HTML/CSS interface, using percentage widths for the sidebar and main content area. This would larger resolutions to take full advantage of the extra space.

We should make each connection to the web server be handled in a separate thread.

This will prevent some browsers (e.g. Chrome) from having issues when attempting to load page content and CSS simultaneously.

The inbox and sent message listing pages should contain pagination. They should not pull back or show all messages on one page.

This will require new BitMessage API methods that allow you to limit the number of results returned.

In message listings (inbox and sent) and message pages, currently the full BitMessage addresses are always shown.

If the BM address has an associated label in the address book, the label should be shown instead of the full address in all the locations mentioned above.

Currently you have to create an identity using BitMessage directly before it can be used in Mirror Messaging.

We should provides pages to allow you to create and manage identities from within the web interface.

Perhaps enforce creation of deterministic BM addresses only, using a number of words from a word list (similar to the Electrum bitcoin client).

Now chans are supported in PyBitmessage, we should provide the ability to add them directly via Mirror Messaging.

This may require creating code for upsteam PyBitmessage to add chan creation support to the API.

For easy reference, we should show the connectivity status of the BitMessage client in the sidebar.