Fix misnamed parameter in log line

Make websocket bind to the host in the specified URI

It's especially confusing to try to debug this if there's still a
websocket server running at the place you're wrongly connecting to...

Switch React sources to cdnjs to work behind https

Prefer sans-serif typefaces

Clicking on buddies in the buddy list opens chats with them

And assorted restructurings.

conv log: add spaces between timestamp, sender, and message

widgets: small string and comment changes

ribbon: emit signal when IMs are sent successfully

Add propTypes to everything that takes React props

frontend: many things

- Allow switching between tabs with click
- Sending messages works and appends to chat log
- Make IMs received propagate to conversation tabs

Handle null buddy icon on icon update

This makes no sense.  WHY WOULD THIS HAPPEN?  But it does.

Remove old React testing classes.

I think I have a more comprehensive React reference here by now.

A mostly-working three-panel page

I think I'm finally getting the hang of React.

Allow multiple ribbon worker processes in different folders

For now, spawn one ribbon per websocket. This will likely need to be revised
later.

Switch ribbon to use unix sockets

They're more secure and I can instantiate multiple sockets in separate
directories without having to probe server ports.

Refactor JS, rename a couple CSS classes

Expose buddy icon changes

Add a command-line argument --state-dir for purple data

Update README. ribbon_passthrough serves its own assets.

End-to-end connectivity demo

Enough tornado and react.js to get events passing from browser to chat network
and back.

ribbon: send packets sans null-terminator

conversations: use the parameter you validated, dummy

refactor, status messages, incoming typing notifications

ribbon: plumbing for sending IMs

I think I might have to create a conv_im object or something before I can
actually send messages.

ribbon: extract connections into a class

TODO: much cleanup

ribbon: emit events for buddy signing on

TODO: figure out what the universe of events we want to support looks like

ribbon: extract blist into separate class

ribbon: extract accounts and conversations into separate classes

ribbon: Extract account management into a separate class

ribbon: dispatch network event to ribbon manager

Dispatch some basic events to the network socket

Add minimal README

Parse and validate messages as JSON

Disconnect clients that send invalid frames
Log the invalid frames and the hex

qmake-qt5 compatibility

Length-coded framing for socket reads

Messages go on the wire as:

struct message {
    uint32_t length;
    uint8_t data[length];
}

and are correctly decoded.

Add a TCP socket server

TODO: actually make said server do anything useful.

WIP on ribbon, a Qt libpurple client

WIP on making a bitlbee gateway

Summary: I'm just testing phabricator

Test Plan: run some things some time

Reviewers: jl

Reviewed By: jl

Differential Revision: https://phabricator.brohaus.com/D2

First pass at a tornado-powered async IRC client

All it does is connect and answer pings, but it can handle the basics of
the protocol.

It can be subclassed to build something which is interested in hooking
into all the messages received.

Make links use url_for and blueprints

Users can create an account.

They can't bind it to a chat network or anything yet though.

Login/logout.

Note that there's no user creation flow yet, so you'll have to manually
frob your DB to test this at the moment.

WIP: Add API skeleton using Flask-RESTful

avoid name conflict on 'api'

Basic templates, helpers, login page

Doesn't actually do anything, but exercises:

1) Flask-WTF
2) CSRF tokens
3) Templating
4) Static files

Initial commit

Flask skeleton, basic database schema, migration infrastructure.