Background

The goal of this project is to allow anyone to send a short text message to someone only knowing their domain name. The receiver should be able to get the message in whatever way they want (SMS, Email, Twitter DM, etc) without the sender knowing what medium the message will be sent through.

(For a bit of background on why abstracting the delivery mechanism is useful, see the communication protocols of Tantek and myself.)

Also see conversations from the #indiewebcamp IRC channel on July 30 and July 31, 2011.

Goals

• Knowing nothing besides a person's URL, be able to send them a short text message.
• Easy to implement, both on the software side as well as the infrastructure side.
  • This most likely means a protocol on top of HTTP, since if you have a web page you already support HTTP.
  • We don't want to require massive amounts of setup and configuration (Jabber, SMTP) since that is not always possible on hardware that powers IndieWeb sites.
• The recipient, not the sender, should decide how the message is ultimately delivered.
  • i.e. I may want to get IMs if I'm at my computer, but SMSs if I'm out and about. The sender shouldn't have to figure out which way I like to receive messages.

Protocol Summary

Given Alice and her site, alice.com, and Bob and his site, bob.com.

• Alice writes a message
• alice.com sends to bob.com
• bob.com asks alice.com "did you send this message?" and presents a small factoring problem to solve
• alice.com says "yes" and provides the answer to the facorization, and bob.com sends the message to Bob

Detailed Flow

• Alice logs in to her website at alice.com
• Alice composes a message addressed to bob.com and hits "submit"
• Alice's server generates a unique ID for this message and stores it locally
• Alice's server makes a post request to bob.com containing:
  • POST http://bob.com/ from=alice.com&text=hello&message_id=1234
• Bob's server (bob.com) receives the request purporting to be from alice.com and needs to verify the message was actually initiated by alice.com
• Bob's server takes the message ID and sends it back to alice.com, along with a factorization problem
  • POST http://alice.com/ message_id=1234&challenge=FactorInteger[2434500]
  • Alice's server looks up the message_id to see if it sent that message, and if so, answers the factorization
  • The answer will be in the Mathematica format for FactorInteger, which will look like
    "{{2,2},{3,2},{5,3},{541,1}}"
• Bob's server compares Alice's server's answer to its known answer and if it matches, accepts the message
• Bob's server can then send the message to Bob
• Bob can be reasonably sure that Alice originated the message

Protocol

Receiving

• When receiving a message, accept POST requests to "/" on your domain with the following form fields:
  • from, text, message_id
• To confirm the message is really from the declared sender, make a post request to http://{from}/ with the post body message_id=####&challenge=FactorInteger[###] given the message ID you were sent, and an arbitrary integer.
  • You can vary the integer based on how much you trust the originating IP address, so you could present new IPs with more difficult factorization problems than trusted IPs. A trivial choice which can be solved instantly is 1.
• The response from the remote server will be the answer to the factorization using syntax, ({{1,1}}), or denied, at which point you can decide where to send the message.

Sending

• To send a message to a remote server, make a POST request to http://example.com/ with the following form fields:
  • from, text, message_id

$ curl -d from=http://example.com -d text=hello -d message_id=1234 http://aaronparecki.com/

• The remote server will query your server (specified in "from") and pass it a challenge and the message_id you provide, so you will need to respond to that request and the challenge.
• You should respond with the answer to the challenge in Mathematica syntax ({{1,1}}) if you confirm you sent the message, or denied based on whether you recognize the message_id specified.

Implementations

• PHP: https://github.com/aaronpk/IndieWeb-Messaging

When implementing this service on top of an existing framework like Wordpress or Mediawiki, you can add an Apache RewriteRule to intercept the POST request before the framework gets a hold of it.

Insert this before any other RewriteRule declarations. This matches a POST request to "/" and routes it to a file called message/receive.php

RewriteCond %{REQUEST_METHOD} ^POST
RewriteRule ^$ /message/receive.php [QSA,L]

This prevents this script from interfering with any existing code you might have on your site, as long as no existing code expects to handle post requests to http://example.com/.

Benefits

• The protocol confirms that the sender did in fact originate the message
• Extremely simple to implement, since no signatures or cryptography is needed
• Can be secured by using SSL
• Can discourage or prevent spam by making the spammers solve factorization problems in order to deliver messages. In theory, it's not worth the spammers time to solve the problem and they will just move on.

Drawbacks

• Does not encrypt or verify the message contents
• Potentially subject to a DoS attack

List of Current Implementations

• aaronparecki.com
• brennannovak.com

Comments

To leave a comment on this page, write a post on your own website and send me a message using this protocol! I will update this page with a link to your site.