fmsg: Structured Host-to-Host Messaging with Verifiable Threads
draft-mennell-art-fmsg-structured-messaging-01

Network Working Group                                         M. Mennell
Internet-Draft                                               Independent
Intended status: Informational                               6 July 2026
Expires: 7 January 2027

    fmsg: Structured Host-to-Host Messaging with Verifiable Threads
             draft-mennell-art-fmsg-structured-messaging-01

Abstract

   fmsg is a message exchange protocol between domain defined hosts.
   Messages are binary encoded and form threads which require
   participation to reply to.

   This document describes the motivation and architecture of fmsg, an
   existing protocol specification and implementation are referenced,
   but the full specification is not included here.  The purpose of this
   document is to solicit IETF feedback on venue and scope before/if the
   specification can develop into standards-track documents.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://markmnl.github.io/fmsg-internet-draft/draft-mennell-art-fmsg-
   structured-messaging.html.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-mennell-art-fmsg-
   structured-messaging/.

   Discussion of this document takes place on the Applications and Real-
   Time Area Area mailing list (mailto:dispatch@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/dispatch/.
   Subscribe at https://www.ietf.org/mailman/listinfo/dispatch/.

   Source for this draft and an issue tracker can be found at
   https://github.com/markmnl/fmsg-internet-draft.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

Mennell                  Expires 7 January 2027                 [Page 1]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   4
     4.1.  Domain Defined Hosts  . . . . . . . . . . . . . . . . . .   5
     4.2.  Messages  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Threads . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Participants  . . . . . . . . . . . . . . . . . . . . . .   6
     4.5.  Message Exchange  . . . . . . . . . . . . . . . . . . . .   7
       4.5.1.  Exchange Model  . . . . . . . . . . . . . . . . . . .   7
       4.5.2.  Message Acceptance  . . . . . . . . . . . . . . . . .   7
       4.5.3.  The Challenge . . . . . . . . . . . . . . . . . . . .   8
   5.  Scope of this Document and Request for Feedback . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

Mennell                  Expires 7 January 2027                 [Page 2]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

1.  Introduction

   This document introduces fmsg, an open message exchange protocol that
   provides ownership and control at the domain level.  First the
   motivation for fmsg is discussed from three main points: efficiency,
   structured threads and built-in verifications.  Then the architecture
   is discussed: domain defined hosts, messages, threads and the
   protocol steps to perform message exchange.

   Much of the architecture of fmsg is based on: fmsg is just messages.
   To receive a message, an fmsg address belonging to a domain has to
   send it to you.  Group conversations emerge as participants reply to
   messages and add additional recipients over time.

   Scope and request for feedback is made with suggestion on future
   document structure splitting the message definitions, protocol and
   transports.

2.  Terminology

   This document uses the following terms:

   Address: An fmsg address in the form @user@example.com identifying a
   recipient within a domain.

   Client: An end application that sends and receives messages belonging
   to a particular Address via their Host.

   Host: An implementation of the fmsg protocol responsible for sending
   and receiving messages to and from other fmsg hosts.

   Sending Host: The Host transmitting a message.

   Receiving Host: The Host receiving a message.

   Message: An immutable data structure containing all the fields,
   content and attachments.

   Thread: A directed acyclic graph (DAG) of messages formed by
   references from each message to a previous message.

   Recipient: An Address identified in a message as an intended
   recipient.

   Sender: The Address originating a message.

Mennell                  Expires 7 January 2027                 [Page 3]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

   Participants: The Sender and all Recipients of a message.  Only
   Participants may reply to a Message or add additional Recipients to a
   Thread.

3.  Motivation

   The design of fmsg was motivated by three primary objectives.

   First, to provide the most efficient practical message exchange while
   preserving the capabilities that have made Internet email successful.
   In particular, fmsg retains unsolicited messaging, multiple
   recipients, any media type, file attachments and ownership and
   control at the domain level.

   Second, to make conversation structure part of the protocol itself.
   Rather than relying on application-specific heuristics to reconstruct
   message threads, fmsg messages explicitly reference previous messages
   using cryptographic hashes.  This allows participants to
   independently construct deterministic, verifiable message threads and
   enables 1) verifying prior participants, and 2) consistent
   presentation of conversations across implementations.

   Finally, to integrate sender verification and message integrity into
   the message exchange protocol.  Rather than relying solely on
   complementary protocols or deployment-specific mechanisms, fmsg
   incorporates these properties into the architecture of message
   exchange itself.  This is intended to simplify host deployment and
   operating hosts.  The combination of sender verification and proof of
   prior participation (enabled by threads) helps inform implementation
   filtering policies.

4.  Architectural Overview

   This section describes the architecture of fmsg in terms of its core
   objects (messages, threads, participants and hosts) and the message
   exchange between hosts that ties them together.

   The architecture is guided by several core principles.  Ownership and
   control remain at the domain level.  Messages are immutable and
   exchanged independently between hosts.  Message threads are
   deterministic and verifiable by all participants.  Sender
   verification and message integrity are incorporated into the message
   exchange protocol.  The protocol intentionally defines only the
   exchange of messages, leaving concerns such as user identity,
   authentication, message retrieval and client functionality undefined.

   The following subsections describe these principles and how they
   relate to one another.

Mennell                  Expires 7 January 2027                 [Page 4]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

4.1.  Domain Defined Hosts

   Every fmsg address belongs to a domain, and each domain is
   responsible for operating one or more Hosts authorised to send and
   receive messages for addresses within that domain.  Messages are
   exchanged directly between Sending Hosts and Receiving Hosts
   responsible for the sender's and recipients' domains.

   Hosts are looked up by the fmsg sub-domain name which also serves as
   a list of authorised hosts.  The Receiving Host can challenge the
   Sending Host during transmission for the digest of the full message
   being sent supplying the digest of the header received so far.
   Recipient policy and message size are checked before downloading the
   message content and any attachments.  Messages and their attachments
   can be compressed with zlib-deflate.  Messages can be accepted/
   rejected for each recipient belonging to a Receiving Host.

   The core protocol defines only host-to-host message exchange.  It
   does not define how users are authenticated, how addresses are
   provisioned, how messages are retrieved by clients, or how messages
   are stored within a domain.  This allows domain owners to retain
   control over their own infrastructure, operational policies and user
   management while interoperating with other hosts through the fmsg
   message exchange protocol.

4.2.  Messages

   The fundamental object in fmsg is the message.  Messages are
   immutable, structured binary objects with a reference to a parent
   message they are in reply to, if any; otherwise a message without a
   parent reference starts a thread.

   Messages are immutable.  Once created, the contents of a message
   never change.  Corrections, replies, forwarding a message to
   additional Recipients and other conversation activity are represented
   by creating new messages rather than modifying existing ones.  This
   immutability provides a stable foundation for verification, message
   integrity and conversation history.

   Each message has exactly one Sender and one or more Recipients.
   Messages may contain arbitrary content represented by a Media Type
   and may include zero or more attachments each with their own Media
   Type.  The protocol places no restrictions on the application
   semantics of the message content, allowing the exchange of plain
   text, rich text, images, audio, video or application-specific data.

Mennell                  Expires 7 January 2027                 [Page 5]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

   Messages are exchanged independently between Sending Hosts and
   Receiving Hosts.  The relationship between messages, including
   replies and conversation evolution, is described by the thread model
   rather than by the messages themselves.

4.3.  Threads

   A Thread is formed by messages explicitly referencing previous
   messages.  The first message in a Thread has no parent, while each
   subsequent message references the message to which it replies.  A
   Thread is therefore an emergent protocol object; the protocol defines
   only messages and the relationships between them.  As messages
   receive independent replies, a Thread naturally forms a directed
   acyclic graph (DAG).

   By making message relationships explicit, every Participant can
   deterministically reconstruct the same Thread from the same set of
   messages.  Replies reference an earlier message, allowing only newly
   created message content to be transmitted while preserving the
   context and ordering of the conversation.

   The Thread model also provides a consistent basis for conversation
   policy.  Because the Participants of a message are explicitly
   defined, a Receiving Host can determine whether a Sender is
   authorised to reply to a message and how additional Recipients become
   Participants in the Thread.  The protocol therefore defines
   conversation evolution in terms of new immutable messages rather than
   modification of existing messages.

4.4.  Participants

   A Participant is the Sender or a Recipient of a Message.

   Only a Participant of a Message can reply to that Message.  This
   ensures that conversation participation is explicit and verifiable,
   and prevents unrelated parties from introducing messages into an
   existing Thread.

   A Participant may add additional Recipients to a Thread by creating a
   copy of the message with additional fields - which original
   Participant is adding the Recipients and the additional Recipients
   being added.  Existing Messages are never modified.  Instead,
   conversation membership evolves as new Messages are created,
   preserving the immutability of every Message while allowing
   conversations to naturally expand over time.

Mennell                  Expires 7 January 2027                 [Page 6]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

   Because Participants are determined from the Thread itself, every
   Host can independently determine the Participants of any Message
   without requiring additional protocol state.  This provides a
   consistent foundation for participant validation, conversation
   presentation and implementation-specific policy decisions.

4.5.  Message Exchange

4.5.1.  Exchange Model

   Message exchange occurs directly between a Sending Host and one or
   more Receiving Hosts.  A Sending Host is responsible for transmitting
   a Message to one Receiving Host per domain in the Message's
   Recipients.  Each Receiving Host processes the Message independently
   and determines whether it will be rejected outright, or rejected/
   accepted by individual recipients belonging to the Receiving Host's
   domain.

4.5.2.  Message Acceptance

   Message acceptance is based on three complementary validation stages:
   Sender validation, Message validation, and Recipient validation.  A
   Receiving Host completes each validation stage before accepting a
   Message.

   Sender validation establishes that the Sending Host is authorised to
   exchange Messages on behalf of the Sender's domain and, where
   required, that it possesses the Message being transmitted.  This
   validation provides assurance that the Message originates from an
   authorised Host.

   Message validation confirms the integrity and consistency of the
   Message itself.  This includes validating message structure, size
   constraints, replay status, and the Message's ancestry within the
   Thread to ensure the Message can be incorporated into a consistent
   and verifiable conversation history.

   Recipient validation determines whether each Recipient is willing to
   accept the Message.  This includes validating recipient-specific
   policy, verifying that the Sender is permitted to communicate within
   the context of the Thread, and applying any implementation-specific
   acceptance policies.  Because Recipient validation is performed
   independently by each Receiving Host, acceptance decisions remain
   under the control of the recipient's domain.

Mennell                  Expires 7 January 2027                 [Page 7]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

4.5.3.  The Challenge

   A distinguishing feature of fmsg is the automatic challenge.  While a
   Message is being received, and before its content is accepted, a
   Receiving Host may open a separate connection back to the Sending
   Host and challenge it for details of the Message currently being
   transmitted, supplying a digest of the Message header fields received
   thus far.  The Sending Host responds by computing and returning a
   digest over the pending Message.

   Because the challenge is directed at the Sending Host using address
   information independently verified against the Sender's domain
   beforehand, a successful response demonstrates that the Sending Host
   is reachable at an authorised address, and once the digest is
   verified to match that of the message, the Sending Host was genuinely
   in possession of the Message sent.  This strengthens both Sender
   validation and Message validation, and imposes a small cost on the
   sender that helps deter unsolicited bulk messaging.

   The challenge is optional and performed at the discretion of the
   Receiving Host, allowing protocol assurances to be traded against
   efficiency.  The detailed mechanism is defined by the protocol
   specification rather than this document.

5.  Scope of this Document and Request for Feedback

   This document deliberately describes only the motivation, design
   goals and core architecture of fmsg.  It does not define message
   encodings, the on-the-wire protocol procedures, or transport
   bindings.  Those details exist today in an experimental specification
   [FMSG-SPEC] and reference implementation [FMSGD], and are intended to
   be specified separately as the work matures.

   The anticipated document structure separates the work into:

   *  this architectural overview;

   *  a message format document defining the binary message structure;

   *  a host-to-host protocol document defining the exchange procedures,
      including the challenge-response mechanism and message acceptance;
      and

   *  one or more transport binding documents (for example, a TCP and
      TLS binding).

Mennell                  Expires 7 January 2027                 [Page 8]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

   The author is seeking feedback from the IETF community on the
   following questions, rather than a detailed review of the underlying
   specification at this stage:

   1.  Is the IETF an appropriate venue for this work, and is the
       Applications and Real-Time (ART) area, by way of the DISPATCH
       working group, the right place to start?

   2.  Is there interest in standardising such a domain-level messaging
       protocol distinct from Internet email?

   3.  How much do existing or in-progress works affect new protocol
       work like this, when would the IETF prefer alignment and
       reconcilement rather than a new protocol?

   4.  This document covers an application-level protocol; in addition,
       Media Types and DNS are used.  Should each area be engaged
       separately?

6.  Security Considerations

   The fmsg architecture is designed around validation before
   acceptance.  A Receiving Host validates a Message before accepting it
   into a Thread.  This model ensures that sender verification, message
   integrity and recipient policy are evaluated before a Message becomes
   part of the recipient's conversation history.

   The optional separate connection a Receiving Host can open to the
   Sending Host, the challenge, poses a threat of a denial-of-service-
   style attack where many, possibly spoofed, addresses trigger
   Receiving Hosts to open many connections to an unsuspecting host.
   The protocol prevents such an attack by requiring Receiving Hosts to
   verify that the origin IP address of an incoming Message exists among
   the authorised IP addresses of the purported sender's domain.

   The protocol standardises the information available to make message
   acceptance decisions while intentionally leaving operational policy
   to Receiving Hosts.  Implementations may apply additional measures,
   including spam filtering, rate limiting and abuse detection, when
   determining whether to accept a Message.

   Operational security considerations, transport security, denial-of-
   service mitigations and other implementation guidance are outside the
   scope of this document and are expected to be defined by the
   corresponding protocol specifications.

Mennell                  Expires 7 January 2027                 [Page 9]
Internet-Draft   fmsg: Structured Host-to-Host Messaging       July 2026

7.  Implementation Status

   This document describes an architecture that has been implemented and
   evaluated through experimental software.

   A complete protocol specification, including message definitions and
   protocol procedures, has been developed [FMSG-SPEC].  A canonical
   implementation following updates to the specification exists [FMSGD].
   This implementation has been used to iterate development hand-in-hand
   with evolution of the specification.

8.  IANA Considerations

   This document has no IANA actions.

9.  Informative References

   [FMSG-SPEC]
              Mennell, M., "fmsg Protocol Specification", n.d.,
              <https://github.com/markmnl/fmsg>.

   [FMSGD]    Mennell, M., "fmsgd Reference Host Implementation", n.d.,
              <https://github.com/markmnl/fmsgd>.

Acknowledgments

   The author thanks any review, feedback and implementation in advance.

Author's Address

   Mark Mennell
   Independent
   Email: markmnl@fmsg.io

Mennell                  Expires 7 January 2027                [Page 10]