How FastCast compares to BitMessage

We launched FastCast because we were unable to find a protocol that would allow for simple message broadcasting through a peer to peer network.

There are a few architectural differences between FastCast (as we imagine it will develop) and BitMessage protocol:

• we do not plan to protect client's IP too much. The relays do not publish client's IP addresses, but there is no focus whatsoever on hiding them. Instead, we expect clients who require privacy to hide behind TOR, or another anonymising service
• while the protocol provides a modest message signing support, it doesn't provide message encryption. If you want your message encrypted, just find out if the receiver uses FastCast, find out his/hers GPG key, and publish a broadcast aimed at him/her
• client, relay and UI are separate; relays communicate through REST. Because of this, if you want to create an app for broadcasting messages through FastCast, you don't have to force your users to set up a relay, or install additional code. You can do that using just a few lines of code

The obvious problems compared to BitMessage:

• creating clients is easy, but if you want to hide your IP, you need to set up TOR as well
• there is no standard for sending non-broadcasted messages. yet.
• the system is not yet distributed - although there is roadmap for that
• no spam prevention yet, but a proof of work requirement should be quite easy to implement once the need arises
• there is no QT client, but there is a web interface supported by relays