gargron / baron

Baron is a WebRTC-based IM for the browser

Baron

Baron is a WebRTC-based web application that allows people to have peer-to-peer text, audio and video conversations with permanent accounts and contact lists.

The back-end is written in JavaScript (Node.js), the signaling channel uses Socket.io. The front-end is written in Ember.js. Authentication is done using Mozilla Persona.

Currently a work in progress.

Configuration

Some configuration is stored in environmental variables. Database-related configuration is stored in the database.json file in the root of the application. Here is an overview:

• BARON_SECRET - no default, cookie secret
• BARON_PORT - 3000 by default, port under which NodeJS is run
• BARON_AUDIENCE - Address of publically accessible website (required for Mozilla Persona verification)
• BARON_SOCKET_AUDIENCE - Address of publically accessible socket.io instance, fallback to BARON_AUDIENCE
• BARON_ENV - database environment to use, default is dev

The database.json file ought to look like this:

{
  "dev": {
    "driver": "pg",
    "user": "baron",
    "password": "some-password",
    "host": "127.0.0.1",
    "database": "baron"
  }
}

Contributing

We are using ember-tools to generate Ember modules and compile them into the final JavaScript file. You'll need to install ember-tools:

npm install -g ember-tools

And whenever you want to make changes to the front-end, you can run this:

ember build -w

to watch the front-end files for changes and rebuild automatically. See the ember-tools documentation for more information.

baron's Issues

Support /me and /emote

It is basic functionality for a chat client to have a basic emote function.

Fix getting stuck in "ringing" state if correspondent goes offline or denies offer

Currently the Contact object for the correspondent will stay in the "trying to connect" stay unless the user on the other end accept the offer in some way. Of course, if the other user declines the offer, or leaves the site, no feedback will be sent to the original caller.

For going offline, the solution is simple. Just reset the peer state as if on hangup. The offer to the other user will be lost anyway.

For declined offers, it's more complicated. If we implement a simple timeout on our end, after which we would reset the peer state, the other user might try to send us an answer to the offer at a later time, which would throw an invalid state exception and do nothing else.

Perhaps declines would need to be transferred through the signaling channel as well.

Handle conflicting state when both peers call each other at the same time

The fix at e36c842 didn't actually work because the accept callback passed to the event handler is inherently bound to the old peer connection.

Remove static from audio ping and convert to .ogg

The .wav ping file is too large and has audible static hiss above 11 kHz.

Add support for automatic hyperlinks

Handle multiple socket.io connections of the same user

Currently the last socket.io connection of a user to be established takes place in the user.sid property, and whenever a connection is closed, the sid will be set to null, even if the user is still online in a different tab.

This probably requires using an array for the sid property, and using socket.io rooms (user == room, all user's connections join a room, dispatch messages to user to that room).

Make it work with browsers other than Firefox

Introduce abstractions that would choose available prefixes for WebRTC objects and handle browser-specific quirks.

Introduce blocking of contacts

Add a UI action to block a contact, which would put the contact in a special state, removing it from the contacts list of the blocker and of the blocked person, and preventing any further contact requests to be shown to the blocker in the future.

Draw attention to messages and calls

Through sounds and a blinking document title. Needs to go away when document is focused.

Make contact lists and users persistent

Move data to a persistent database instead of storing them in memory. Currently a lot of pointers are being thrown around.

Hardcoded address for the Socket.io client

The address to which the Socket.io client will try to connect is hardcoded, and cannot currently be set through environmental variables (ideal solution).

Automatically establish text chat connections

Instead of showing the offer/answer process to the user, try to automatically establish a data channel to user's contacts.

Store conversations in browser's memory, and allow synchronization on start-up.