1. XHMTP
    1. Goals/Principles
    2. Basic Assumptions
    3. Example messaging lifecycle
      1. Message Notification
      2. Message Fetching
    4. Other links

XHMTP

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.

Goals/Principles

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: 
    XYZ
  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