mnm open source

m.n.m
 FAQ • Demo • Download • Contact

Frequently Asked Q’s

Stuff you wanted to know, and weren’t afraid to ask

  1. Why a new message protocol?

    Email reliability is falling, its security is nil, and its content model has been stagnant for decades. It’s no longer acceptable for business communications.

    A huge variety of services & sites send time-sensitive and/or private information to their members/customers electronically. Those that can afford it do this via custom phone apps, or SMS texts containing URLs to a customer portal. All the rest are forced to rely on email, which is not suitable for urgent or confidential content.

    Protocols like SMTP & Matrix were designed to connect anyone on the Internet with anyone else. That entails one or more third party intermediaries to relay messages; such entities incur costs, present external points of failure or attack, and may scan/monetize traffic. Using TMTP, organizations can exchange messages with their customers/members directly, without intermediate hosts.

  2. Isn’t SMTP entrenched? How can TMTP replace it organically?

    Today, TMTP offers a better, cheaper solution for sites that have already abandoned SMTP (or that want to) in favor of custom phone apps or SMS texts carrying website links. These sites will expose the majority of Internet users to the end-user benefits of TMTP.

    Over time, departments within orgs will adopt TMTP for internal correspondence. Besides the productivity gains versus email, TMTP is especially valuable for environments where an email-borne cyberattack could be catastrophic, e.g. manufacturing, public infrastructure, government, finance, R&D, IT. See also SMTP Delivers Disaster.

    Professional associations, and other services which can verify their members’ identities, will offer TMTP accounts to facilitate trustworthy introductions and correspondence among individuals and businesses.

    TMTP won’t replace all SMTP use cases, nor impact consumers’ use of popular messaging services. The messaging space will remain a diverse one.

  3. What is the architecture of TMTP?

    Email vs. TMTP Networking

    Succinctly stated: client-server, store-and-forward, members-only. All sent and received data is stored on the clients; the server does not retain messages after delivery. The organization that established a TMTP service controls who can register clients with it; only registered clients are allowed to connect. If a member registers multiple clients, the server forwards messages to all of them. The client-server links support both sending and receiving messages.

    A user is expected to have memberships at numerous sites, as in the real world. At each server, the user has a separate membership identity, and one or more human-readable aliases associated with it. The server constrains aliases, e.g. minimum number of characters, no duplicates.

    TMTP defines no server-to-server aspect. Where a site needs to analyze or archive correspondence by its members with other sites, its server could act as a proxy client (not yet defined in protocol draft).

    TMTP relies on a secure stream protocol to carry its traffic. That generally means TCP+TLS, but HTTPS could also work, given a mechanism whereby the server can alert the client (see #7 re mobile clients). For stronger security, a TMTP server could be configured to require client-side TLS certificates.

    See also Supplanting SMTP.

  4. Does TMTP enable a universal identity, the way email does?

    No, it provides site-specific identities. The issue of universal identity is complex, and should not be defined within a messaging protocol. If a separate universal identity system is widely adopted, TMTP servers could accept its tokens as user registration credentials. Providers of universal identity would let users receive notifications via a variety of messaging schemes, including TMTP.

  5. Does TMTP provide end-to-end encryption (E2EE)?

    Not yet, but it’s planned. E2EE wouldn’t be the default for all TMTP sites, as there are legitimate reasons why a site would need to analyze or archive traffic among its members.

    E2EE is not as important for TMTP as it is for SMTP. When the Internet was emerging, its constituent networks weren’t online continuously, therefore email between networks had to be stored at each relay node until the next one was accessible. That exposes the message content to every node in the path, regardless of any encryption at the transport layer. TMTP (like HTTP) simply assumes a robust Internet.

  6. Why doesn’t TMTP offer federation between servers?

    It isn’t necessary, and it would open an easily exploited social engineering pathway. When you receive an invitation to correspond or a message, you need to know who has control over the sender’s stated identity. If it’s your organization, it’s trustworthy. If it’s a vendor you buy from infrequently, it may not be. If it’s a semi-public service that verifies real-life identities, do you have confidence in its verification?

    Furthermore, your home provider in a federated network can accidentally or intentionally cut off your service, and record all of the sites you correspond with, and read or copy all the content you receive or send, and even impersonate you in messages to anyone.

    See also #4, re universal identity.

  7. How does TMTP support mobile clients with variable-quality Internet connections?

    The protocol draft needs work in this area. JMAP specifies a client-side listener which the server can ping to prompt the client to reconnect for pending messages. That could be a template for a TMTP feature.

  8. Why does the TMTP protocol draft define both message delivery and message body formatting?

    The definition of acceptable message formats could be a separate protocol, but for now, there’s one protocol draft.

    The server doesn’t enforce the protocol for message formatting (see protocol op “Post” under “.datahead segment”). Special-purpose clients that don’t send messages to normal clients can use whatever message format suits them.

  9. Couldn’t one implement all these features on the existing email protocol stack?

    Repurposing SMTP/etc to implement TMTP wouldn’t work well, nor help adoption. Existing email servers & clients wouldn’t understand any of the messages!

  10. Doesn’t another protocol already provide these features, e.g. Matrix or JMAP?

    Matrix & JMAP are synchronization protocols, wherein both sides maintain a copy of the data objects in question. Matrix is federated (see #6 re federation) and highly complex. JMAP is an extension of the email protocol stack, fitting between user apps and email hosts.

  11. Will TMTP be standardized; if so, when?

    Yes, after we gain real-world experience with the protocol, and have a community of folks who want to see it codified.

  12. Is “mnm” really the best name for the project?

    Good question! I think it rolls off the tongue nicely (say em • eh • nem). And the general public might get a kick out of the self-referencing quirk—Mnm is Not Mail. Plus you can invent your own names from the acronym; it’s Massive New Mail!

To pose a question not addressed above, feel free to open or comment on an issue: