Internet-Draft | Everything | June 2023 |
Hallam-Baker | Expires 30 December 2023 | [Page] |
https://mailarchive.ietf.org/arch/browse/mathmesh/Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at .¶
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/.¶
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 30 December 2023.¶
Copyright (c) 2023 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.¶
Everything is a document format, notification structure and protocols that provide a consistent and coherent infrastructure for human interaction through the Internet.¶
All existing modalities of human Interaction addressed by existing Internet protocols are supported, these include:¶
Despite the wide scope of Everything's capabilities, the adoption of a consistent approach to all forms of messaging with end-to-end security built in allows a considerable reduction in client complexity.¶
Everything builds on existing approaches. Where possible, existing protocols and infrastructure are adopted without modification (e.g. use of WebRTC for voice and video interaction). In other cases, existing formats are adapted.¶
Everything is an Open Infrastructure in which there are no gatekeepers determining who is allowed to provide service, any user may use the service provider of their choice and change their choice of service provider without switching costs.¶
Everything Text Markup Language (ETML) is an XML markup built on a subset of HTML that is purely focused on the expression of content. Presentation capabilities such as choice of fonts, size, color etc. are intentionally omitted.¶
Specifying a separate markup language for Everything messaging permits HTML features that are undesirable or present security risks to be omitted. ETML does not support presentation capabilities such as choice of fonts, size, color etc. ETML documents MUST NOT include any form of scripting or active code capability.¶
ETML is divided into three tiers, each of which of represent the content capabilities commonly used in a set of existing interactions:¶
Basic text formatting of single paragraphs of text with emphasis (italic, bold, underline, etc.) with links to remote content and included images and video.¶
Typical uses include chat messages, comments and annotations on documents.¶
Structured texts with titles, subtitles and section headings.¶
Typical uses include mail messages and blog posts.¶
Richer structured texts with captioned images etc.¶
Intended for use in longer articles and papers.¶
Advanced notations such as markup for mathematics, chemistry, physics, chess, etc. are supported through use of an extension schema (e.g. MathML for mathematics) with alternative presentation in SVG being provided if the recipient does not have the ability to render the markup.¶
Restricting user content to a limited repertoire according to context simplifies presentation of interactions in a comprehensible format. While texts such as Daniel Bomberg's 1519 edition of the Talmud demonstrate the practicality of presenting a base text, commentaries and commentaries on the commentary on a single page, attempting to present a book length commentary as response to a single paragraph of a base text is clearly absurd.¶
Restricting user content also simplifies authoring and permits clients to act as gateways to legacy communications infrastructures (SMTP email, proprietary social media platforms).¶
Everything Notification Message (ENM) is a message format used to provide notification of content being available, In the case of very short text content, the notification may include the content itself.¶
ENM messages consist of a DARE envelope containing a JSON body presenting the notification itself. This allows use of existing protocols used to synchronize DARE Sequences to be used to synchronize exchange of notifications.¶
The ENM schema is based on the widely used RSS format to facilitate interoperability. The chief difference being that an RSS feed is an XML document which must be replaced every time an item is added while an ENM sequence is an append only log. Thus, while an RSS feed typically contains only the most recently updated items, an ENM sequence can contain the entire publication feed without performance penalty.¶
Support for the full range of interactions used in messaging, social media, mail etc. requires a wide range of services. As shown in section [TBS], support for social media interactions alone involves six separate roles and four different types of service. But even though the number of services is large the use of ENS messages encapsulated in DARE Sequences allows most of the interactions between these services to be implemented by a synchronization of DARE sequences.¶
Support for the following services allows an Everything application to support the full range of functionality in both the authoring and receiving modes:¶
Clients advise publishers of the availability of new content using the Mesh Service Post Mechanism.¶
Static content that is longer than the maximum payload of a Mesh Message is published using the HTTP POST method.¶
Deliver notification of the arrival of new content and feedback.¶
The Mesh Presence service is used to support synchronous messaging. Every device that is accepting inbound communication requests to a Mesh account maintains a constant connection to the corresponding presence service which acts as a broker and access control enforcement point for inbound communication requests.¶
Streaming of audio and video content is provided by WebRTC under symmetric keys exchanged through the Mesh Presence service.¶
The protocols supporting these services are either existing standards (e.g. WebRTC) or represent codification of existing practices that have evolved over decades within the consistent approach provided by the Mesh Architecture.¶
The internal identifier used to uniquely identify Mesh accounts is the UDF fingerprint of the root signature keys(s) of their Mesh profile. Since a string of 20 or more characters of Base-32 characters offers poor usability, provision is made to allow use of DNS account addresses and/or Mesh callsigns instead.¶
A DNS Account Address is of the form defined in [RFC822] (account@domain) where domain is the DNS address of the Mesh Service Provider servicing the account and account is a text label uniquely identifies a particular Mesh account serviced by a provider. Mesh Clients MUST support use of internationalized domain names [RFC5890] and UTF8 Unicode addresses.¶
A Mesh callsign is of the form @account
as specified in [draft-hallambaker-mesh-callsign]. In normal circumstances, a callsign is a lifelong address that a once issued, a user can hold without payment of any renewal fee or other form of rent.¶
The separation of the internal identifier from the human readable form allows users to make use of multiple account addresses and callsigns for the same account. The primary purpose of the human readable form is to facilitate contact exchange rather than to support addressing.¶
For example, Alice initially registers her account with example.com
which assigns her the address alice@example.com. She then registers the callsign @alice
and @alice-lastname
. Finally, Alice changes her service provider example.net
which assigns her the account address alice68@example.net
as the account 'alice
' is already taken there.¶
If Bob exchanges Mesh contact details with Alice, it is the contact entry in his address book used to send the message rather than alice@example.com
, alice68@example.net
, @alice
, etc. Thus, he can enter any of these forms to send a message to Alice because the contact entry he has for Alice is bound to her permanent account fingerprint and is automatically updated when Alice changes her service provider.¶
If Carol attempts to use the address alice@example.com
after Alice has moved to example.net
, the contact exchange will only succeed if example.com
has not assigned Alice's account identifier to a new user and provides forwarding service to Alice's new account.¶
This section presents the related specifications and standards on which Everything is built, the terms that are used as terms of art within the Mesh protocols and applications and the terms used as requirements language.¶
This document makes use of the terms defined in [draft-hallambaker-mesh-architecture].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].¶
As its name suggests, Everything is designed to support the widest possible range of human interactions. But unlike the World Wide Web in which Web content is understood to be content that can be accessed using the vast majority of current Web browsers, it is not expected that every Everything client will support every form of interaction supported by Everything. The communication modalities supported by an application necessarily depends on the affordances offered by the device it is running on. While a user is very likely to perform collaborative editing of a document on a desktop or laptop, they are much less to be doing so on their smartwatch.¶
One of the chief advantages of deploying a new interaction infrastructure is the ability to apply a consistent security approach to every form of interaction.¶
All user generated content is authenticated. All user generated content is end-to-end encrypted unless explicitly designated as public by the author.¶
In cases where the set of authorized recipients is not known at the time content is generated or is subject to change, the content is encrypted under the key of a threshold encryption group and decryption of the content controlled by a Mesh key service.¶
Every interaction is gated by access control.¶
Everything interactions are always brokered by one or more services. In the case of an asynchronous interaction, the broker is either the Mesh Service Provider of the recipient or a collaboration service host supporting a subset of the Mesh Service Protocol operations. In the case of a synchronous interaction, a Mesh Presence Service is used to establish a session. In each case, the inbound connection broker is responsible to perform access control on the communication request. Thus knowing the address or callsign of an Everything user does not in itself grant the ability to wake them at night and attempt to sell them double glazing.¶
Establishing a direct communication channel between the initiator and responder in a synchronous messaging or streaming interaction is most efficient but may compromise the privacy of the participants. IP addresses provide a powerful tracking tool that may expose the participants location or other identities.¶
This concern may be efficiently addressed by introducing proxy forwarders. Since the RUD transport protocol ignores the packet source address, separate proxy forwarders may be used on the inbound and outbound connections.¶
If a forwarder is trusted by both participants and third party traffic analysis is not being considered as a threat, a single stage of forwarding is sufficient. This approach is shown in Figure 1.¶
If third party traffic analysis is a concern or the forwarders are not trusted, a multi-level onion routing network may be established with different packets taking different routes through a network whose usage patterns are concealed by traffic from other parties and the use of flood fill approaches. This approach is shown in Figure 2.¶
From a protocol point of view, asynchronous messaging services such as SMS only differ from email in the message sizes supported. Since SMTP is a push protocol in which the receiving mail server must accept and store the entire mail message on receipt, the message size is necessarily limited according to site policy. The maximum message size accepted is rarely more than a few MB and so larger data transfers are typically achieved by sending a link from which the receiver may retrieve the data from a clous service. Thus users are required to make use of three separate applications for very short messages, longer messages and very large data sets.¶
In the Everything Mail model (Figure 3), a sender passes messages to a receiver through a four-corner model. If the message is small enough to fit inside a notification, the sender first forwards the message to their own service provider who forwards it to the service provider acting for the receiver from which the receiver may collect the message to read on their various devices.¶
The outbound and inbound service providers perform access control on the notification request.¶
The maximum notification message size is intentionally limited to a small value, currently 32KB. This has performance and implementation advantages. There is little point in synchronizing a streaming video file of several GB in length to the user's watch. Limiting notification message size allows an approach in which every Everything device downloads the complete notification spool.¶
Transfer of longer messages is supported through a pull interaction in which the notification message contains only the message title and either an EARL providing the location of the encrypted resource and a decryption key in the case of a private message or a link to the resource in the case of a public message (Figure 4).¶
The notification-pull interaction removes the need to limit the size of messages transferred in the protocol, the only limit being the storage capacity available at the sender and receiver.¶
This interaction is not currently fully specified. The following capabilities should be considered:¶
Note that since a client MAY retrieve the message payload automatically without user interaction, message retrieval MUST NOT be considered proof of the message being read by a recipient. If a read receipt capability is required, this should be provided through a separate cryptographic enforcement mechanism such as Mikali fair contracts protocol.¶
Asynchronous collaboration in closed communities presents a subset of the requirements of a global scale social network.¶
For example, consider the case of a group of authors collaboratively editing a document through an annotation service. Authors read the document and associated annotations published by the Annotation Host and post their comments to the Annotation Host in response (Figure 5).¶
Comments made on a document MAY be tagged with a lightweight semantic as introduced by the [Open Meeting]. These tags provide context to tools designed to support document editors, highlighting parts of the document that need correction, clarification or further discussion.¶
Establishing a synchronous text messaging interaction between two users presents a number of challenges:¶
These requirements are addressed through the use of a presence service. Whenever a device that is connected to a Mesh account is willing to accept inbound interaction requests, it maintains a constant connection to a presence service. To establish an interaction the initiator sends the request to the presence service servicing the account which performs an access control check on the request and if accepted, notifies the responder's connected devices. If the responder accepts the request, a bilateral communication channel is established between the initiator and the responder (Figure 12).¶
Establishing a synchronous voice or video interaction between two users presents essentially the same set of requirements as for text messaging but with the additional requirement of supporting streaming audio or video. Since the WebRTC protocols already provide this capability, it suffices to use the Mesh Presence service to establish the connection and perform the necessary key exchange (Figure 13).¶
One important limitation of this approach is that WebRTC is not designed to provide the same degree of traffic analysis resistance as the Mesh RUD transport. Another consequence of this design is that support for WebRTC capabilities on most platforms currently comes in the form of a captive Web Browser widget that is invoked by a parent application. While this approach offers all the power and rich functionality of Web technologies such as CSS and JavaScript, it also presents the accompanying attack surface.¶
Conferences and meetings offer streaming content but are structured as an interaction in which participants interact with a central host (Figure 14).¶
While Everything is in principle capable of peer-to-peer meeting model, the social scaling challenges for structuring conversations of more than four people make use of such a scheme implausible.¶
Everything Text Markup Language is a lightweight document markup designed for use in social media interactions. Unlike HTML 4.0 and later version which are primarily intended to provide presentation capabilities, ETML is focused on representing content and structure.¶
One consequence of this more limited focus is that the ETML schema makes minimal use of attributes.¶
Element identifier, may occur in paragraph type elements¶
Class identifier, may occur in paragraph type elements.¶
The schema for ETML is shown in Section 9.¶
ETML Level 1 is intended for representation of chat messages, comments and other short messages. There are two top level elements:¶
The <p> element may contain any of the following elements:¶
Element | Name | Description |
---|---|---|
i | Italic | Italic text |
b | Bold | Bold text |
u | Underline | Underlined text |
del | Deleted | Deleted text |
ins | Inserted | Inserted text |
tt | Fixed font | Fixed font |
a | Anchor | Link to external resource |
sub | Subscript | Subscript |
sup | Superscript | Superscript |
dfn | Definition | Mark surrounding paragraph as the definition of the term contained |
img | Image | Image data |
svg | SVG | Inline Scalable Vector Graphics markup (see TBS) |
video | Video | Video data |
bdi | Bidirectional | Bidirectional Isolation. |
alt | Alternative | Contains a list of content blocks containing alternative descriptions of the same content. |
[]¶
ETML level 2 contains the elements of level 1 with the addition of structural elements to identify titles, headings, lists, etc. typically used in email messages, blog posts and other short articles. There is one top level element:¶
Post containing structured text data.¶
The additional tags specified in the level 2 repertoire mostly define specialized forms of paragraph style.¶
Element | Name | Description |
---|---|---|
post | Post | Post containing structured text data. |
title | Title | Post title, a post may only have one title. On a mail message, the title is the subject. |
subtitle | Subtitle | Subtitle, a post may have multiple subtitles |
h1 | Heading 1 | First level heading |
h2 | Heading 2 | Second level heading |
h3 | Heading 3 | Third level heading |
h4 | Heading 4 | Fourth level heading |
dt | Tag | Defined tag |
dd | Data | Defined data |
li | Bullet | Bulleted list item |
ni | Numbered | Numbered item |
pre | Preformatted | Preformatted text used for examples, etc. |
quote | Quotation | Incorporate element from another post |
cite | Citation | Source citation. |
Tables are omitted from the Level 2 model on account of table editing capabilities presenting a considerable degree of complexity.¶
ETML Level 3 contains additional structural elements required in the production of articles, books and reports. There are two top level elements:¶
The Level 3 markup adds features such as the ability to nest lists, add footnotes, endnotes, and captions and to mark document sections.¶
Element | Name | Description |
---|---|---|
document | Document | Container for document elements. |
fragment | Fragment | A document fragment which contains documents elements but is not necessarily a complete document. |
cap | Caption | Captioned paragraph, image or video item |
meta | Meta | Metadata describing the document. |
tp | Tagged | Tagged paragraph belonging to a particular collection. |
list | List | Container for list elements |
foot | Footnote | Footnote presented in body of the text |
end | Endnote | Endnote presented at the end of a document |
section | Section | Section heading, used to divide longer document into sections |
author | Author | Identifies an author |
abstract | Abstract | Marks a set of paragraphs as an abstract |
preamble | Preamble | Document preamble |
main | Main | Marks the beginning of the main section of a document that begins with a foreword or abstract |
postamble | Postamble | Marks the end of the main section of the document. Headings within the postamble will be marked as appendices. |
table | Table | Table, as in HTML model |
The ETML level 3 markup borrows heavily from the document markup specified in [RFC7991]. ETML documents may be converted to RFC7991 format and back again with little loss of information.¶
The <tp> element may be used to specify a tagged paragraph. Tagged paragraphs may be used to mark a paragraph as a lemma or theorem.¶
ETML paragraphs and paragraph sequences MAY include an SVG element containing SVG content with the following restrictions:¶
This document requires no IANA actions.¶