Version 5 (modified by Daniel Kahn Gillmor, 11 years ago) (diff)



This is a project to try to define (and implement) an asynchronous messaging protocol capable of supplanting SMTP, without adopting any of SMTP's more noxious characteristics. Yes, that's ambitious.


Not all of these goals are met, unfortunately. Nonetheless, they're the goals.

  • reuse existing infrastructure and well-known protocols
  • costs of sending should be borne by the sender; avoid recipient-pays situations as much as possible
  • integrated strong cryptographic support (including message integrity, verifiable authorship, and privacy)
  • anonymous messages should still be possible (though they may be discarded by per-user policy)
  • avoid centralized or hierarchical authority
  • individual agents should be able to pool resources to participate
  • individual agents should not need to share resources to participate
  • universal connectivity: no walled gardens
  • robust to failures of systems involved

Basic Assumptions

  • asynchronous messaging happens with a single sender and 1 or more recipients. These are the messaging endpoints.
  • the endpoints may be humans or software
  • endpoints have well-connected agents that may act on their behalf. These agents are online more reliably than the endpoints themselves.

Example messaging lifecycle

This describes the steps taken during the transmission of a single message. The message is sent by a human (alice) who belongs to or controls a domain (A). We can call the sender alice@A as shorthand. The message's recipient is bob, who belongs to domain B. We can imagine the message also going to cheryl@C.

Each domain (A, B, and C) offers a server that is better-connected than the relevant endpoints. We'll call the server for domain A server-a.A.

Message Injection ==

  1. alice's MUA sends message to server-a.A (how? HTTP POST? submission?)
  2. server-a authenticates sender according to user/domain-specific policy.
  3. server-a generates message identification string ($ID)
  4. server-a stores message in alice's message queue, labeled $ID
  5. server-a generates message access code string for each recipient ($RS_B, $RS_C...)
  6. server-a stores the following in notification queue: (bob@B, $ID, $RS_B) ; (cheryl@C, $ID, $RS_C) ...

Message Notification

server-a takes an item out of the notification queue and attempts to notify the agent of the recipient endpoint. In this example, we assume that the item selected is (bob@B, $ID, $RS_B):

  1. server-a does srv lookup _xhmtp._tcp.B, which returns:
    _xhmtp._tcp.B server-b.B 80
  2. server-a does txt lookup _prefix._xhmtp.B, which returns:
  3. server-a does HTTP POST to: http://server-b.B/XYZ/bob@B which includes the following:
    • message url: http://bob%40B:$RS_B@server-a.A/.*/alice/$ID (note the HTTP basic auth username and password in the domain part -- these are the auth credentials that keep the message private)
    • message headers (what are permissible?)
  4. server-b extracts hostname from message url in post, and checks DNS A record against server-a
    • uses standard HTTP return codes for notifications
    • possible per-user filter strings (whitelists, blacklists, etc.)
    • the IP address of the "message url" should match the IP address of the connecting notifier
  5. server-b generates RSS feed for message for bob

Message Fetching

  1. bob requests RSS feed from server-b
  2. When/if bob wants to read the relevant message, his RSS reader retrieves it from server-a