This document describes a protocol for a distributed-server communication system, tentatively called FMTP (Flexible Message Transfer Protocol).

The types of messaging this protocol could support include:

• Email
• Instant Messaging
• Blogging/Public Forums
• Chat Rooms
• More?

Architecture

• An FMTP system is distributed and scalable. Anyone may run a server, provided it has a name that can be resolved. Much of this mechanism is identical to an SMTP system. A major difference from SMTP is that data may be requested as well as delivered. Additionally, an 'ideal route' may be negotiated.

Objects

• FMTP defines data as discrete objects. A user is an object, as is a server, an email, etc. Each object has attributes that define it.

Route negotiation

• The user and host objects include a description of the best way to make contact, including hostname or IP, port number, and protocol (TCP/UDP). When communicating with an object, the first step is to retrieve the object and its properties. This can be done in the following ways:

• Local Cache
  • Perhaps we've looked up this object recently
• Parent Cache
  • If we are in a hierarchal organization, perhaps our local server has looked up this object recently
• Domain
  • Connect to the MX server of the target domain, and retrieve the object
• Parent Lookup
  • If we cannot connect directly to the target domain, we can ask our parent to look up the object for us.

  BROnce we have the object, it will tell us the best way to make contact. The following methods may be used to connect to a known object:

• Recommended
  • Connect in the way the object describes
• Domain
  • If the object cannot be contacted directly, connect to the domain's MX server.
• Parent
  • If you cannot connect directly to the target domain, we can ask our parent to deliver our message.

Messages

• Messages can describe objects, or request objects. As an example, a client might request the user object of each 'buddy' when it starts up. The response would include online/busy status. The client may also send its user object to each online buddy when the online/busy status changes.

Public Objects

• Objects marked as public will be freely given to anyone who asks. Public status is ideal for blogs or bulletins, as well as shared files etc. A list may be obtained, showing all available public objects.

Abuse Prevention

• An encrypted hash will be sent with each message to verify it. To prevent monopolization by a single controlling entity, DNS will be considered authoritative. A DNS query to the target domain will retrieve the public key, for decrypting the hash. I don't recall the name, but somewhere I read a well-written description of this method intended for use with SMTP. A question - When a client with no resolvable name connects directly to another, how do they verify?

Threads, or object relation

• Multiple objects may be related such as emails and replies, all the messages in a chat session, a blog and its comments, etc. Each object will be given a unique ID when it is created. The ID, combined with the user address (1239583738491.user@domain) should be universally unique. Probably based on a timestamp and perhaps another nonce. Each object may have a parent attribute, specifying the object ID that it is linked to. For example, a reply will have the original message as its parent. For different uses, the parent might be the immediately preceeding object, or the toplevel object of the thread. Perhaps both a parent and a top attribute would be handy?